SQL 如何通过执行计划判断是否走索引？

确认是否走索引需查看执行计划中operator是否为Index Seek或Index Scan，且Object为索引名（如IX_Users_Email）而非表名；若为Clustered Index Scan或table Scan则未有效利用索引。

看执行计划里有没有出现 Index Seek 或 Index Scan，同时确认对应操作的 Object 是你的索引名（比如 IX_Users_Email），而不是表名（比如 Users），基本就能确定走了索引。

重点关注“Operator”和“Object”两列

在 sql Server 的执行计划（图形或 xml）中，找到数据检索那一步（通常是最右边或最上层的“聚集索引扫描/查找”“非聚集索引查找/扫描”等节点）：

• 如果 Operator 是 Index Seek：说明走了索引，并且是高效地定位到具体行（通常有谓词，如 WHERE Email = 'a@b.com'）
• 如果 Operator 是 Index Scan：也走了索引，但扫描了整个索引（可能因条件不满足 SARG 性、索引选择性差，或没写 WHERE）
• 如果 Operator 是 Clustered Index Scan 或 Table Scan：没走非聚集索引，甚至可能连聚集索引都没用好——这时候要警惕全表扫描
• 右键点击该操作 → 选“属性”，看 Object 值：如果是 [IX_Orders_Status] 就是用了索引；如果是 [Orders] 或 [PK_Orders]（且你本意想用非聚集索引），说明优化器没选你期望的索引

留意“Estimated number of Rows”和“Actual Number of Rows”

这两项差距过大（比如预估 1 行，实际返回 10 万行），往往意味着统计信息过期或查询条件导致优化器误判，它可能因此放弃索引而选了扫描。这时即使写了 WHERE status = 'done'，若该值占表 95%，SQL Server 很可能直接扫表。

• 运行 UPDATE STATISTICS TableName WITH FULLSCAN 更新统计信息
• 检查字段的 数据分布：高重复值（如性别、状态码）单独建索引效果差，考虑联合索引或过滤索引

注意“Warnings”和“Missing Index”提示

图形执行计划里，如果有黄色感叹号图标，鼠标悬停会显示警告，常见如：

• “No Join Predicate”：关联没写 ON 条件，容易引发笛卡尔积，索引失效
• “Convert issue”：比如 WHERE mobile = 13800138000（字段是 VARCHAR），隐式转换会让索引无法 SEEK
• “Missing Index”：SQL Server 主动建议建什么索引——不是必须照做，但值得验证是否真能提升性能

用 SET STATISTICS XML ON 辅助验证

比图形界面更直观看到底层决策：

• 执行前加 SET STATISTICS XML ON，再跑查询
• 在结果栏点开 XML 执行计划，搜索 或 ，看 Index="[YourIndexName]"
• 检查

  内容，确认 WHERE 条件是否被下推到索引层（即真正用于查找，而非查完再过滤）