EF Core 用 FromSqlRaw
执行 SELECT 查询（带实体映射）
想让原生 SQL 返回强类型实体，必须用
FromSqlRaw配合 DbSet，且 SQL 查询列名、顺序、类型需与实体完全匹配。EF Core 不做字段映射或类型转换，错一个就抛
InvalidOperationException。
常见错误：SQL 中用了别名但没和属性名一致；SELECT * 但表里有计算列或 NULL 值导致类型不兼容；忘了加
AsNoTracking()导致无谓性能开销。
FromSqlRaw只能用于
DbSet<t></t>，不能用于普通 IQueryable 或 List SQL 必须返回所有实体属性对应字段，不可少、不可多（除非实体用
[NotMapped]标记多余字段） 参数化防注入必须用
{0} 占位符 + params object[]，例如：
context.Users.FromSqlRaw("SELECT * FROM Users WHERE Age > {0}", 18)
若只需部分字段，建议新建轻量 DTO 类，并用 FromSqlRaw+
AsEnumerable()后手动投影，EF Core 不支持原生 SQL 直接映射到匿名类型或非实体类
EF Core 调用存储过程或无返回结果的 SQL（INSERT/UPDATE/DELETE）
用
ExecuteSqlRaw（EF Core 5+）或旧版
ExecuteSqlCommand，它只返回影响行数
int，不涉及实体映射。
容易踩的坑：传参时误用字符串拼接；执行含多个语句的 SQL（如先 SET NOCOUNT ON 再 SELECT）导致异常；在事务外调用却期望一致性。
参数仍须用{0} 占位，不可写成 "WHERE Id = " + id存储过程中若含
SELECT结果集，
ExecuteSqlRaw会忽略，要读结果必须改用
FromSqlRaw或 ADO.NET 若需获取新插入记录的 ID（如 SQL Server 的
SCOPE_IDENTITY()），
ExecuteSqlRaw无法返回，得用
Database.GetDbConnection()拿底层连接手写 ADO.NET
需要返回标量值或自定义结构？绕过 EF Core 映射直接走 ADO.NET
EF Core 原生 SQL 能力有限：不支持多结果集、不支持 OUT 参数、不能返回
DateTimeOffset等未映射类型、也不处理存储过程中的临时表逻辑。这时必须切到原始 ADO.NET。
关键点是复用 EF Core 的连接生命周期——别自己 new SqlConnection，而要用
context.Database.GetDbConnection()，确保连接打开状态与 EF 事务一致。 连接未打开时需手动
Open()，但注意 EF Core 可能已管理该连接，重复 Open 会报错 用
DbCommand设置
CommandType = CommandType.StoredProcedure调用带 OUT 参数的过程 读多结果集用
reader.NextResult()，EF Core 的
FromSqlRaw完全不支持这个 记得用
using包裹 command 和 reader，避免连接泄漏
为什么 FromSqlInterpolated
比 FromSqlRaw
更安全？
FromSqlInterpolated是 C# 字符串插值语法的封装，它自动把插值变量转为参数化查询，从根本上防止 SQL 注入。而
FromSqlRaw若拼接用户输入，等于裸奔。
但它的限制也很实在：只支持单个插值表达式，不能拼复杂逻辑；不支持插值后加额外 WHERE 条件；且插值内容必须是变量或常量，不能是方法调用（如
$"..." + GetCondition()会绕过参数化）。 正确用法：
context.Products.FromSqlInterpolated($"SELECT * FROM Products WHERE Price > {minPrice}")
错误写法：context.Products.FromSqlInterpolated($"SELECT * FROM Products WHERE Price > " + minPrice)—— 这彻底退化为字符串拼接 不支持插值中嵌套三元运算符或空合并：用
??或
?:会导致编译失败，得提前算好值再插
EF Core 的原生 SQL 支持本质是“有限透传”，不是万能替代。真正复杂的查询、多结果、动态列、权限控制逻辑，迟早得切到 ADO.NET；而日常简单定制查询，选对
FromSqlRaw/
FromSqlInterpolated/
ExecuteSqlRaw这三个入口，比硬套 LINQ 更快也更可控。
