EF Core索引生效需满足三条件：字段顺序匹配WHERE最左前缀、迁移已执行、查询未用函数；复合索引应按Status、CreatedAt顺序创建并指定排序方向，优先使用Fluent API而非[Index]注解，注重覆盖索引与统计信息更新。
EF Core 索引不是“加了就快”，字段顺序错、迁移没跑、查询写了函数，三个地方一踩全白搭。
复合索引字段顺序必须匹配 WHERE 条件的最左前缀
数据库只从左到右匹配索引字段。你查 WHERE Status = 'Pending' AND CreatedAt > '2025-01-01'，那索引必须是 Status 在前、CreatedAt 在后。
- 错误写法：
HasIndex(x => new { x.CreatedAt, x.Status })→ Status 单条件查不到，Status + CreatedAt 也用不上 - 正确写法：
HasIndex(x => new { x.Status, x.CreatedAt }).IsDescending(false, true)→ 支持 Status 单查、Status+CreatedAt 联合查、ORDER BY Status, CreatedAt DESC - 布尔数组顺序必须和字段顺序严格一致：
IsDescending(false, true)表示第一个字段升序、第二个降序；写反了不会报错，但排序行为不符合预期
[Index] 注解能用但限制多，别指望它干复杂活
[Index] 看起来省事，实际项目里容易卡在细节上：
- 不支持排序方向：
[Index(nameof(Status), nameof(CreatedAt))]无法指定CreatedAt DESC - 不支持包含列（INCLUDE）：想把
Id和Name一起放进索引避免回表？不行，得用 Fluent API + 原生 SQL 或迁移脚本 - 不支持筛选索引（如
WHERE IsDeleted = 0）：SQL Server 的 filtered index 必须绕过注解，改用modelBuilder.SqlServer().UseFilteredIndex(...)或手动写迁移 - 继承场景下作用范围过大：[Index] 会打到所有派生类对应表上，而
HasIndex可以精确控制到某个具体实体类型
索引建完查询还慢？先看这三件事做了没
很多“索引无效”问题根本不是索引本身的问题，而是落地环节漏了：
- 没执行迁移：
Add-Migration AddOrderStatusIndex后忘了Update-Database→ 数据库里压根没这个索引 - 字段类型不一致：C# 中定义为
string，数据库列却是nvarchar(max)→ SQL Server 可能拒绝走索引；加[StringLength(200)]显式约束长度更稳妥 - 查询用了函数：
.Where(x => x.Name.ToUpper() == "ABC")→ 数据库无法使用Name索引；要么改写成不带函数的写法，要么建计算列并为其加索引
覆盖索引和统计信息比索引数量更重要
与其堆一堆单列索引，不如盯住高频查询路径做覆盖：
- 如果常查
SELECT Id, Name, Status FROM Orders WHERE Status = @s ORDER BY CreatedAt DESC，那就建一个(Status, CreatedAt DESC) INCLUDE (Id, Name)—— 所有字段都在索引里，不用回表 - EF 日志里看到大量
Key Lookup操作符？说明非聚集索引没覆盖查询字段，该加 INCLUDE 了 - 执行计划里“估算行数”和“实际行数”差十倍以上？大概率是统计信息过期，手动执行
UPDATE STATISTICS [Orders]再试
真正难的不是怎么写 HasIndex，而是搞清楚你应用里哪几条查询被调得最勤、返回数据最多、又恰好落在同一组过滤字段上——这些才是值得花时间建复合索引的地方。其他都是干扰项。
