确认是否走索引需查看执行计划中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 条件是否被下推到索引层（即真正用于查找，而非查完再过滤）
