为何SQL Server中MIN(row_id)执行索引扫描而非索引查找？

前提背景 #

• 表包含10亿+行数据，row_id为非空int列：row_id int NOT NULL
• 创建了分区非聚集索引：

  CREATE NONCLUSTERED INDEX row_id_IX ON dbo.test_table (row_id ASC)
  

• 查询需求：获取row_id的最小值，执行语句：

  select min(row_id) from test_table
  

• 预期行为：利用B+树特性，递归查找根节点左子节点直到最左叶子节点，直接获取最小值；实际行为：优化器选择执行索引扫描，全量读取10亿行后通过聚合得到结果。

核心原因：分区索引的结构限制 #

分区索引本质是多个独立的B+树集合，每个分区对应一个独立的索引树。导致优化器无法直接定位全局最小值的关键因素如下：

• 分区键与索引键不匹配：如果你的分区键不是row_id，那么每个分区内的row_id是局部有序的，但全局最小值可能存在于任意一个分区中。SQL Server无法仅通过扫描某一个分区的最左节点来确定全局最小值，必须遍历所有分区的索引数据，才能确保找到真正的最小值。
• 统计信息不准确：如果表的统计信息过时，优化器无法准确评估各个分区的数据分布情况，可能误判"全索引扫描"的成本低于"逐个分区查找最小值再比较"的成本，从而选择全扫描执行计划。

验证与解决建议 #

1. 确认分区键：检查表的分区策略，若分区键是row_id，优化器应该能直接定位到第一个分区的最左节点获取最小值；若分区键为其他列，则必然需要扫描所有分区。
2. 更新统计信息：执行以下语句更新统计信息，让优化器获得准确的数据分布：

   UPDATE STATISTICS dbo.test_table WITH FULLSCAN
   

3. 强制索引查找（谨慎使用）：可以尝试强制优化器使用索引查找，但需测试性能：

   SELECT MIN(row_id) FROM dbo.test_table WITH (INDEX(row_id_IX))
   

   注意：如果分区数量较多，逐个分区查找最小值再全局比较的成本可能高于全扫描，需根据实际情况选择。

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