EF Core执行原生SQL需用FromSqlRaw（查询）或ExecuteSqlRaw（增删改），必须参数化防注入；查询须匹配实体或DTO，非查询操作返回受影响行数，标量查询用SqlQueryRaw，注意大小写敏感及不支持LINQ链式调用。
EF Core 执行原生 SQL 很简单，但要注意安全、适用场景和写法细节。核心是用 FromSqlRaw（查询）或 ExecuteSqlRaw（增删改），配合参数化防止 SQL 注入。
查询数据：用 FromSqlRaw + 实体类型
必须配合已映射的实体类（或自定义 DTO + AsNoTracking），SQL 返回字段要和实体属性名/类型尽量匹配。
- 基础写法：
context.Blogs.FromSqlRaw("SELECT * FROM Blogs WHERE Id = {0}", id) - 推荐用命名参数：
context.Blogs.FromSqlRaw("SELECT * FROM Blogs WHERE Name LIKE @name", new SqlParameter("@name", "%ef%")) - 如果返回字段不完全对应实体，可搭配
AsNoTracking()和Select投影到匿名对象或 DTO
执行非查询操作：用 ExecuteSqlRaw
适合 INSERT / UPDATE / DELETE / 存储过程等不返回实体结果的操作。
- 示例：
context.Database.ExecuteSqlRaw("UPDATE Blogs SET Name = {0} WHERE Id = {1}", newName, id) - 同样强烈建议用参数化，避免拼接字符串
- 返回值是受影响行数（int），可用于判断是否成功
执行标量查询（如 COUNT、SUM）：用 SqlQueryRaw
EF Core 5.0+ 支持直接查单个值或简单类型：
var count = context.Database.SqlQueryRaw("SELECT COUNT(*) FROM Blogs").Single() - 注意：类型必须严格匹配 SQL 返回类型（比如 COUNT 返回 bigint，用
long更稳妥） - 不能用实体类，只能是基础类型或自定义轻量 DTO（需有匹配构造函数或可空属性）
注意事项和避坑点
原生 SQL 是“绕过 EF”的操作，灵活性高但失去部分 ORM 优势。
- 不参与 EF 的变更跟踪 ——
FromSqlRaw返回的实体默认是AsNoTracking状态 - 表名/列名大小写敏感（尤其在 PostgreSQL 或开启区分大小写的 SQL Server 设置下）
- 不能在
FromSqlRaw后链式调用 LINQ 方法（如.Where()），EF 不会翻译；如需组合，先查出再内存过滤，或重写进 SQL - 存储过程调用可用
FromSqlRaw("EXEC GetBlogs @p0", id)，但输出参数需额外处理（EF Core 不原生支持）
基本上就这些。用得好能补足 LINQ 表达能力不足的场景，用不好容易埋下维护和安全隐患。
