EFCore的FromSqlRaw方法可执行原生SQL查询，但需注意安全与性能。必须使用参数化查询防止SQL注入，不可在方法后链式调用LINQ条件以免内存过滤。查询结果列必须与实体属性严格匹配，建议避免SELECT*并显式指定列。纯读取场景应使用AsNoTracking以提升性能。跨数据库时需注意列名大小写与空值映射等细节。
# C# 如何执行原生 SQL：EF Core FromSqlRaw 与参数化查询的核心要点
在 EF Core 中使用原生 SQL 查询时，`FromSqlRaw` 是一个强大的工具，但它也像一把双刃剑——用得好能解决复杂查询需求，用不好则可能引入安全漏洞和性能问题。以下是几个必须掌握的核心要点。
## FromSqlRaw 本身不防注入，必须配合参数化写法才安全
直接拼接字符串等于裸奔。EF Core 的 `FromSqlRaw` 方法不会自动识别变量，它只是将传入的字符串原样传递给数据库——除非你显式提供参数。
**错误写法**：`"SELECT * FROM Users WHERE Name = '" + name + "'"`，这会直接触发 SQL 注入攻击。
**正确做法**是使用位置占位符 `{0}` 或 `SqlParameter`：
```csharp
// 使用位置占位符
context.Users.FromSqlRaw("SELECT * FROM Users WHERE Age > {0} AND Status = {1}", 18, "Active")
// 使用 SqlParameter（更灵活，可控制类型）
context.Users.FromSqlRaw("SELECT * FROM Users WHERE Name LIKE @name",
new SqlParameter("@name", "%john%"))
```
前者依靠 EF Core 自动转换为命名参数（如 `@p0`），后者则可以精确控制 `SqlDbType` 和空值处理，通常更稳妥。
## FromSqlRaw 只能用于 DbSet，不能链式调用 Where 等 LINQ 方法
这是一个常见的性能陷阱。你不能在 `FromSqlRaw` 后再写 `.Where(x => x.IsActive)`，因为 EF Core 不会把这些 LINQ 方法翻译成 SQL，而是先执行原始 SQL，然后在内存中进行过滤——数据量大时性能会直接崩盘。
**常见误用**：
```csharp
context.Users
.FromSqlRaw("SELECT * FROM Users")
.Where(u => u.CreatedAt > DateTime.Today) // ❌ 内存过滤！
.ToList();
```
**正确方式**是把条件直接写进 SQL 里：
```csharp
context.Users
.FromSqlRaw("SELECT * FROM Users WHERE CreatedAt > {0}", DateTime.Today)
.ToList();
```
或者改用 `FromSqlInterpolated`（EF Core 5+ 支持），它支持字符串插值且自动参数化，写起来更自然：
```csharp
var cutoff = DateTime.Today;
context.Users
.FromSqlInterpolated($"SELECT * FROM Users WHERE CreatedAt > {cutoff}")
.ToList();
```
## 列名、顺序、类型必须和实体完全一致
`FromSqlRaw` 不做任何字段映射，也不容错。SQL 返回的列必须和实体属性严格匹配：
- **列名必须一致**（大小写敏感，尤其在 PostgreSQL 中）
- **顺序必须一致**（按实体属性定义顺序）
- **类型必须兼容**（比如数据库返回 `datetime2`，实体用 `DateTime?` 却对应了 `NOT NULL` 列）
**常见问题**：
- 少一列 → 未映射属性为默认值
- 多一列 → 直接抛 `InvalidOperationException`
- 类型不兼容 → 运行时失败
**最佳实践**：
1. 别用 `SELECT *`：表结构变更后极易出错
2. 别乱加别名：`SELECT u.Name AS UserName` → 实体必须有 `UserName` 属性
3. 计算列或 `NULL` 值要小心：例如 `SELECT Id, Name, COUNT(*) AS Count`，若实体没 `Count` 属性就失败
需要部分字段？建议新建一个轻量 DTO 类，使用 `AsNoTracking()` + 手动投影，或者换用 `SqlQueryRaw
()`（EF Core 5+）。
## 查询完记得加 AsNoTracking()
`FromSqlRaw` 默认开启变更跟踪，哪怕你只是读取报表数据。这会导致 EF Core 缓存所有实体、监听属性变化、额外分配内存——在纯读场景下毫无必要。
加上 `AsNoTracking()` 能显著降低 GC 压力和查询耗时：
```csharp
context.Users
.FromSqlRaw("SELECT Id, Name, Email FROM Users WHERE IsActive = {0}", true)
.AsNoTracking()
.ToList();
```
**注意**：加了 `AsNoTracking()` 之后，实体不可直接修改提交。如需更新，得重新查询或手动 `Attach`。
## 最容易被忽略的细节
在实际项目中，最常被忽略的是列名大小写和空值处理：
1. **跨数据库迁移时**：PostgreSQL 默认小写，SQL Server 默认不敏感但配置可变
2. **NULL 字段映射**：映射到非可空类型会静默失败或报异常，不是所有环境都开启详细日志
这些问题往往在测试环境不出现，一到生产环境就暴露，需要格外注意。
