ef core复合索引字段顺序必须匹配查询模式，status应置于createdat前以支持单条件及联合查询，并用isdescending(true, false)控制排序方向；[index]不支持包含列、筛选索引和导航属性索引，且继承场景下作用范围过宽；索引未生效常见原因包括未执行迁移、字段类型不一致、查询使用函数导致无法命中；单表非聚集索引建议不超过5～7个，避免写入性能显著下降。
EF Core 索引不是“建了就快”，关键在字段选择、顺序和写入代价的权衡。直接用 HasIndex 或 [Index] 声明索引只是第一步，真正影响性能的是你是否匹配了真实查询模式。
怎么用 Fluent API 创建复合索引并控制字段顺序
复合索引的字段顺序直接影响能否命中——数据库只会从左到右匹配索引字段。比如你常查 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 })→ 覆盖单字段Status、双字段联合查询，还能支持ORDER BY Status, CreatedAt - 如果还要按时间倒序查最新 pending 订单，加
.IsDescending(true, false)（注意布尔数组顺序必须和字段顺序一致）
数据注解 [Index] 的隐藏限制
[Index] 看起来简单，但实际项目里容易踩坑：它不支持包含列（INCLUDE）、不支持指定排序方向、也不能为导航属性生成索引。
- 想给外键 + 时间字段建索引？
[Index(nameof(OrderId), nameof(UpdatedAt))]可以，但无法指定UpdatedAt降序 - 想把
IsDeleted字段作为过滤条件又不常更新？[Index]无法加WHERE IsDeleted = 0这类筛选索引（SQL Server 的 filtered index），必须用 Fluent API 配合原始 SQL 或迁移脚本 - 实体继承场景下，
[Index]会作用于所有子类表，而HasIndex可以精确控制到具体派生类型
为什么加了索引查询还是慢？三个常见漏点
索引建完不等于生效。很多问题出在迁移、数据分布或查询写法上。
- 没执行迁移：
Add-Migration AddProductStatusIndex后忘了Update-Database，数据库里根本没这索引 - 字段类型不一致：C# 中定义为
string，但数据库列是nvarchar(max)，SQL Server 可能拒绝使用索引；改用[StringLength(200)]显式约束长度 - 查询用了函数：写
.Where(x => x.Name.ToUpper() == "ABC")，数据库无法走Name索引；应改用不带函数的写法，或建计算列索引
索引不是越多越好：写入变慢的临界点在哪
每多一个索引，INSERT/UPDATE/DELETE 就要多维护一份 B+ 树。实测中，单表超过 5～7 个非聚集索引时，写入延迟开始明显上升，尤其在高并发批量导入场景。
- 优先保留：高频 WHERE、JOIN、ORDER BY 涉及的字段组合
- 果断删掉：半年没被查询计划引用过的索引（SQL Server 可查
sys.dm_db_index_usage_stats） - 替代方案：对只读报表库，可考虑定期重建索引 + 启用页压缩；但生产 OLTP 库慎用压缩，会增加 CPU 开销
最常被忽略的一点：复合索引里字段顺序一旦定死，就很难靠“加字段”补救——比如已有 (A, B) 索引，再新增 C 变成 (A, B, C) 是可行的，但想让 B 单独走索引，只能另建一个 (B) 索引，而不是修改原索引。
