Azure SQL查询WHERE子句返回高比例行时性能骤降求助

这是典型的统计信息倾斜+查询优化器执行计划选择偏差问题，我来拆解原因并给出具体优化步骤：

问题根源分析 #

当你的表中ColumnA全为0时，SQL Server的统计信息会判定WHERE ColumnA = 0会返回100%的行数据。此时查询优化器做出了糟糕的执行计划选择：

• 它可能先执行全表扫描（或聚集索引扫描），再过滤出ColumnA=0的行（明明所有行都符合条件），接着对29万行数据做排序来满足ORDER BY AnotherColumn，最后取前20行。这个过程里的过滤步骤完全多余，但优化器因为统计信息的单一性（只有0这个值），错误预估了执行成本。
• 当你修改1%的行变为1后，统计信息自动更新，优化器意识到ColumnA=0返回99%的行，这时它会选择和无WHERE子句时相同的高效计划——比如直接基于AnotherColumn的有序索引扫描（如果存在），或者更高效的排序策略，只需要处理少量数据就能拿到前20行，因此耗时骤降。

另外，BIT类型的统计信息本身就容易在数据高度倾斜时出现估算偏差，这进一步加剧了优化器的判断错误。

具体优化方案 #

1. 创建覆盖索引（最优解） #

如果你的查询不需要返回全表列（而非要用SELECT *），优先创建包含排序键AnotherColumn和过滤键ColumnA的覆盖索引，让查询直接走索引有序扫描，无需额外排序：

CREATE NONCLUSTERED INDEX IX_Table_AnotherColumn_Include_ColumnA
ON Table (AnotherColumn)
INCLUDE (ColumnA, [列1], [列2], ...); -- 替换成你实际需要的业务列，避免用*

如果必须用SELECT *，可以创建包含所有列的索引，但不推荐（索引体积过大），最好只保留业务必需的列。这个索引会让查询直接按AnotherColumn有序读取，过滤ColumnA=0后直接取前20行，耗时会降到毫秒级。

2. 手动更新统计信息 #

强制更新表的统计信息，让优化器获得准确的数据分布，即使全表ColumnA都是0，也能选择正确的执行计划：

UPDATE STATISTICS Table WITH FULLSCAN;

执行后再测试原查询，性能应该会和修改1%数据后的情况一致。

3. 使用查询提示强制优化行为 #

如果统计信息更新后还是有问题，可以给查询添加RECOMPILE提示，让每次执行都重新生成基于当前数据分布的执行计划：

SELECT * FROM Table 
WHERE ColumnA = 0 
ORDER BY AnotherColumn 
OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY
OPTION (RECOMPILE);

或者尝试强制使用默认基数估算器（如果你的数据库用新基数估算器存在兼容问题）：

SELECT * FROM Table 
WHERE ColumnA = 0 
ORDER BY AnotherColumn 
OFFSET 0 ROWS FETCH NEXT 20 ROWS ONLY
OPTION (USE HINT('FORCE_DEFAULT_CARDINALITY_ESTIMATION'));

4. 对比执行计划找差异 #

在SSMS中分别执行两种场景（全0和有1）的查询，查看实际执行计划（按Ctrl+M），对比差异：

• 看全0时是否存在多余的Filter运算符，以及排序步骤的成本占比
• 看有1时是否使用了更高效的索引扫描或排序策略
  通过对比可以明确优化器的选择偏差，针对性调整索引或查询逻辑。

额外建议 #

尽量避免使用SELECT *，只查询需要的列，减少数据传输和索引体积；另外，如果BIT类型的ColumnA大部分值固定，可以考虑是否需要保留可为空属性，不过这对性能影响不大。

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