为何带列存储的分区索引视图查询速度更慢？

为什么分区索引会出现额外的SeekPredicate和有序索引扫描？ #

• SeekPredicate的产生逻辑：访问分区索引时，SQL Server必须先通过分区函数定位目标租户对应的分区ID。哪怕你的查询明确指定了单个TenantNumber，优化器仍会生成SeekPredicate来匹配该租户对应的分区边界范围，确保只访问目标分区、避免扫描所有分区——这是分区索引的固有定位机制，属于分区元数据层面的筛选步骤。
• Ordered=true的原因：分区索引的存储结构中，分区键会作为索引键的组成部分（尤其是绑定了分区的唯一聚集索引）；同时列存储索引的分区元数据要求按分区顺序访问。再加上优化器可能判断有序扫描能更好地匹配查询后续逻辑（比如隐含排序需求、避免额外排序操作），因此强制使用了Ordered=true的扫描方式，而非列存储索引通常采用的无序批量扫描。

这是不是查询变慢的直接原因？ #

SeekPredicate本身的开销极小，不会直接导致性能下降，但**Ordered=true的有序扫描+IO_QUEUE_LIMIT等待**才是核心问题：

• 列存储索引的核心优势是并行、批量的无序读取，Ordered=true会限制扫描的并行度，迫使SQL Server按顺序读取数据，直接降低了IO吞吐量。
• IO_QUEUE_LIMIT等待说明IO请求出现排队：分区索引的访问需要额外读取分区方案、分区函数的元数据，再加上有序扫描的IO调度效率远低于无序扫描，导致IO资源利用率下降，最终拉长了查询耗时。

另外，单个租户的索引视图数据量仅3000万，索引更紧凑，无需分区定位的元数据开销，查询时可直接进行高效批量扫描，因此性能比分区索引视图高出约30%。

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