在SQLServer数据库运维与开发过程中，索引选择直接决定了查询语句的执行路径与资源消耗。很多性能问题并不是因为没有索引，而是优化器在多个候选索引之间做出了并不经济的判断，或者已有的索引因为结构不合理而无法被有效利用。理解优化器如何评估索引、怎样设计符合查询模式的索引，是提升系统吞吐量的核心手段。
统计信息如何驱动索引选择
SQLServer的查询优化器是一个基于成本的引擎，它并不会盲目使用所有可用索引，而是依赖统计信息来估算不同执行计划的开销。统计信息主要包含密度向量和直方图两部分，密度向量描述列或列组合的选择性，直方图则记录首列的数据分布。当一张表的索引建立在低基数列（例如性别只有男和女）上时，优化器通过计算得知使用该索引仍需回表访问绝大多数数据页，便会倾向于直接进行表扫描。
在实际环境中，统计信息过期是索引失效的常见诱因。表经过大量增删改后，如果没有启用自动更新统计或者数据变化未触发阈值，优化器持有的分布数据会与真实情况偏离。此时即便存在合适索引，也可能生成错误的计划。我们可以通过以下语句手动更新统计信息并查看其密度：
-- 更新指定表的全部统计信息
UPDATE STATISTICS dbo.Orders WITH FULLSCAN;
-- 查看索引统计信息的直方图与密度
DBCC SHOW_STATISTICS ('dbo.Orders', 'IX_Orders_CustomerId_Status');
除了主动维护，还需要关注统计信息采样率。对于超大型表，默认采样可能只抽取部分数据，导致倾斜分布未被捕获。使用FULLSCAN虽然准确但锁表时间长，因此在业务低峰期执行是较为稳妥的做法。只有让优化器看到真实的选择性，索引才会在该用的时候被用上。
复合索引列顺序与覆盖设计
复合索引的最左前缀原则在SQLServer中同样成立。假设经常执行的查询条件为 WHERE CustomerId = @c AND Status = @s，那么索引应当建立为 (CustomerId, Status) 而非反向。如果写成 (Status, CustomerId)，当查询仅提供 CustomerId 时，该索引便无法被范围或等值命中首列，优化器只能忽略它。列顺序应当贴合查询过滤条件的出现频率与选择性，高选择性且常作为过滤条件的列放在前面。
另一个常见误区是忽视键查找开销。即使索引覆盖了过滤条件，若查询还需输出其他列，SQLServer不得不通过聚簇索引键回到基表取数，这种书签查找在结果集较大时非常昂贵。此时应使用包含列（INCLUDE）将输出列附加到索引叶子层，而不参与索引键排序。例如下面的写法能避免回表：
CREATE NONCLUSTERED INDEX IX_Orders_Cust_Status ON dbo.Orders (CustomerId, Status) INCLUDE (OrderDate, TotalAmount);
覆盖索引能显著减少逻辑读，但也会占用更多磁盘与维护成本。我们需要结合缺失索引动态管理视图来权衡，而不是为每条查询都建一套包含列。通过 sys.dm_db_missing_index_details 可以观察优化器推荐的索引列组合，再依据实际业务频次做裁剪，避免索引膨胀拖累写入性能。
导致索引失效的语句写法与排查
即便索引结构合理，查询语句本身的写法也可能让优化器放弃使用它。最典型的便是对于函数包裹列的滥用，例如 WHERE CONVERT(date, CreateTime) = @d，此时 CreateTime 上的索引因为被函数处理而无法直接定位，只能逐行计算。应当改为范围比较： WHERE CreateTime >= @d AND CreateTime < DATEADD(day,1,@d)，让列以干净形态出现在条件左侧。
隐式类型转换也是隐蔽的杀手。当查询参数类型为 nvarchar 而列定义为 varchar 时，SQLServer往往将列转换而非参数转换，导致索引失效。通过执行计划中的“隐式转换”警告或 SET STATISTICS IO ON 观察逻辑读突增，就能定位问题。以下脚本可快速比对两条写法不同的语句开销：
SET STATISTICS IO ON; -- 错误写法：列被函数处理 SELECT * FROM dbo.Orders WHERE YEAR(OrderDate) = 2023; -- 正确写法：范围扫描 SELECT * FROM dbo.Orders WHERE OrderDate >= '2023-01-01' AND OrderDate < '2024-01-01'; SET STATISTICS IO OFF;
排查时还应养成查看实际执行计划的习惯，而非仅依赖预估计划。实际计划会显示索引查找或扫描的真实行数，以及是否发生键查找、并行度溢出等情况。将慢查询放入计划缓存视图 sys.dm_exec_query_plan 中分析，配合索引使用率视图 sys.dm_db_index_usage_stats，就能判断哪些索引常年不被命中可安全删除，哪些高频查询仍缺索引需补充，从而形成良性的索引治理闭环。