移除索引中的列为何提升了SQL Server大表的查询性能？

兄弟我太懂这种「问题解决了，但完全摸不着头脑」的感觉了！咱们来一步步掰扯清楚你遇到的这个诡异情况——

先还原你的场景 #

你手里有个几十亿行的超大表：

• 原来的聚集索引是(A, B)，其中A有几百万唯一值，B只有几千；
• 还有个单独的非聚集索引在B列；
• 核心查询就是WHERE A IN (a1,a2...aN) AND B IN (b1,b2...bM)，大部分时候10秒搞定，偶尔突然拉胯到15分钟，执行计划显示在扫整个聚集索引。

为什么原来的(A,B)聚集索引会掉链子？ #

SQL Server的聚集索引就是表本身，数据是严格按索引键排序存储的。原来的(A,B)排序逻辑是：先把所有相同A值的行聚在一起，再在每个A组里按B排序。

这时候你的查询是「A取N个值，同时B取M个值」，优化器可能会犯个估算错误：它觉得「A的N个值 × B的M个值」的组合行数不多，于是选择直接扫描聚集索引去匹配条件。但实际情况是，几十亿行的表里，这些A和B的组合可能分散在大量不连续的数据页里——相当于你要在一堆按A+B排序的书里，找所有A是某几个值且B是某几个值的页码，得翻遍大半个书架，随机IO直接拉满，时间就崩到15分钟了。

移除聚集索引里的B（改成仅A的聚集索引）为啥就好了？ #

当聚集索引只保留A列时，数据变成按A值连续存储——所有A=a1的行挤在连续的几个数据页里，A=a2的行又在接下来的连续页里，以此类推。

这时候你的查询走聚集索引的逻辑就变了：

1. 优化器可以快速定位到每个目标A值对应的连续数据块（也就是聚集索引Seek）；
2. 在每个A的数据块里，直接过滤符合B条件的行——因为同一A的行都在一起，过滤成本极低，不需要跨大量分散的页扫描。

相当于你现在找书，先把所有A对应的书堆都拎出来，再在每个小堆里挑B符合要求的，工作量直接从「翻整个书架」降到「翻几个小书堆」，时间自然就回到10秒级了。

额外唠唠那个单独的B索引 #

原来的B非聚集索引，存储的是B值+对应的聚集索引键(A,B)，如果优化器选这个索引，回表的时候要拿着(A,B)去找数据——但如果你的A取值很多，回表的次数会爆炸，优化器反而会觉得不如扫聚集索引，结果更糟。而当聚集索引改成仅A后，B索引的回表键变成A，就算优化器选这个索引，回表效率也会高很多，但核心提升还是来自聚集索引的扫描路径优化。

备注：内容来源于stack exchange，提问作者Andriy K