SQL Server查询4天范围无限运行，分批查询却正常执行

问题场景 #

处理基于3张表、总数据量超30亿行的视图tablexyz时，出现如下异常性能问题：

• 查询4天时间范围（2023-02-01T04:10:18 至 2023-02-05T04:10:18）的语句无限运行：

SELECT
    TOP 1 1
FROM
    tablexyz t1 (nolock)
WHERE
    t1.col1 = 1
    AND t1.col2 <= '2023-01-31'
    AND t1.knowledge_begin_date >= '2023-02-01T04:10:18'
    AND t1.knowledge_begin_date <= '2023-02-05T04:10:18'
OPTION(RECOMPILE)

• 将时间拆分为两个2天范围的查询，每个执行时间均不到200ms：

-- 执行时间200ms
SELECT
    TOP 1 1
FROM
    tablexyz  t1 (nolock)
WHERE
    t1.col1 = 1
    AND t1.col2 <= '2023-01-31'
    AND t1.knowledge_begin_date >= '2023-02-01T04:10:18'
    AND t1.knowledge_begin_date <= '2023-02-03T04:10:18'
OPTION(RECOMPILE)

-- 执行时间200ms
SELECT
    TOP 1 1
FROM
    tablexyz  t1 (nolock)
WHERE
    t1.col1 = 1
    AND t1.col2 <= '2023-01-31'
    AND t1.knowledge_begin_date >= '2023-02-03T04:10:18'
    AND t1.knowledge_begin_date <= '2023-02-05T04:10:18'
OPTION(RECOMPILE)

现有索引与执行计划情况 #

现有索引 #

• 非聚集索引 col1_col2_IX：键列为(col1, col2)
• 非聚集索引 kdb_IX：键列为(knowledge_begin_date)

执行计划信息 #

• 长时运行的查询无法获取实际执行计划
• 分批查询的执行计划显示，对3张基表均使用kdb_IX索引查找

可能的原因分析 #

1. 统计信息不准确
   SQL Server查询优化器依赖统计信息估算行数，当时间范围扩大时，若统计信息未及时更新或无法准确反映该范围内的数据分布，优化器可能错误选择低效执行计划（如放弃kdb_IX索引，转而使用col1_col2_IX或全表扫描）。小范围查询时，统计信息能精准估算行数，因此选择了最优的索引查找路径。

2. 成本估算偏差
   当查询的时间范围扩大后，优化器可能认为knowledge_begin_date范围内的行数过多，判断走kdb_IX索引后回表/关联其他表的成本过高，转而选择基于col1_col2_IX的执行路径。但实际数据分布中，col1=1且col2<='2023-01-31'的数据集在大时间范围内仍为小体量，导致优化器的成本估算出现偏差。

3. 视图连接策略变更
   由于视图涉及3张表，时间范围扩大时，优化器可能改变表的连接顺序或连接类型（如从嵌套循环改为哈希连接）。哈希连接处理超大规模数据时会消耗大量内存和CPU，导致查询超时；而小范围查询数据量小，嵌套循环连接成本更低，因此执行高效。

4. TOP 1的执行逻辑差异
   对于TOP 1查询，优化器会优先选择最快找到第一行的路径。小范围查询时，kdb_IX索引可快速定位匹配行并返回；但大范围查询时，优化器可能错误认为遍历col1_col2_IX索引能更快找到匹配项，而实际该索引对应的数据集在大时间范围内几乎无匹配，导致遍历大量数据迟迟无法返回结果，表现为“无限运行”。

验证与解决建议 #

• 更新统计信息：对视图涉及的所有基表执行UPDATE STATISTICS [表名] WITH FULLSCAN;，确保优化器获取准确的数据分布。
• 创建覆盖索引：考虑创建包含所有过滤列和关联列的覆盖索引，例如：

CREATE NONCLUSTERED INDEX IX_col1_col2_kdb ON tablexyz(col1, col2, knowledge_begin_date);

让优化器可直接通过索引完成过滤与关联，无需回表。

• 强制索引使用：在长时查询中添加FORCE INDEX(kdb_IX)或OPTION(FORCESEEK)，强制优化器使用指定索引，验证性能是否提升。
• 对比预估执行计划：查看长时查询与分批查询的预估执行计划，定位优化器的选择偏差点。

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