超大规模表分页查询：A_Index表最优聚集索引选型咨询

首先，咱们先拆解你的核心需求：3000万+数据的分页，靠A_Index的ROWNUMBER快速定位目标页，再关联主表A取数。两种方案的差异本质是聚集索引的排序逻辑是否匹配你的查询优先级。

先分析两种方案的问题 #

• 方案2（ID, [DATE], ROWNUMBER作为聚集索引）：完全踩了分页查询的痛点。聚集索引的排序是先按ID+DATE，再按ROWNUMBER——这意味着你要筛选ROWNUMBER范围时，SQL Server无法直接定位到目标区间，必须扫描大部分索引数据才能找出符合条件的行，这就是你看到耗时更长的根本原因，直接pass。
• 方案1（ROWNUMBER, ID, [DATE]作为聚集索引）：虽然能快速定位ROWNUMBER范围，但额外把ID+DATE加入聚集索引键列是多余的，反而带来两个问题：
  1. 增加了聚集索引的宽度，浪费存储空间和IO资源（因为聚集索引的键会被所有非聚集索引引用，哪怕你现在没有非聚集索引，也会影响数据页的存储密度）；
  2. 导致返回的ID+DATE是按ROWNUMBER排序的，而主表A的聚集索引是ID+DATE，SQL Server可能会选择合并连接来关联，这就需要对A_Index的ID+DATE做排序，产生了你看到的“不必要排序”开销。

最优聚集索引设计 #

既然ROWNUMBER是通过ROW_NUMBER()生成的唯一值（分页的核心筛选键），直接把它作为唯一聚集索引的单一键列就够了：

CREATE UNIQUE CLUSTERED INDEX IDX_AIndex_Rownumber ON A_Index(ROWNUMBER)

这个设计的优势：

1. 极致的范围查找效率：聚集索引按ROWNUMBER有序存储，你的ROWNUMBER > 10000000 AND <=10100000条件能直接定位到目标页的行，不需要扫描额外数据；
2. 避免不必要排序：查询A_Index得到ID+DATE后，SQL Server会优先选择嵌套循环连接，用每个ID+DATE直接去主表A的聚集索引做精准查找——主表的ID+DATE聚集索引本身就是有序的，嵌套循环不需要对A_Index的结果排序；
3. 更小的索引体积：单一键列的聚集索引宽度最小，存储更紧凑，IO开销更低。

额外注意事项 #

• 确保生成A_Index的ROWNUMBER时，排序逻辑和你期望的分页顺序一致（比如如果需要按ID+DATE分页，那ROW_NUMBER()要ORDER BY ID, [DATE]），否则分页结果会不符合预期；
• 定期维护A_Index，比如当主表A有大量数据插入/删除时，要同步更新A_Index的ROWNUMBER，避免分页出现数据遗漏或重复。

内容的提问来源于stack exchange，提问作者Sal