SQL Server非聚集索引未生效，排序结果异常求助

核心问题 #

原查询的WHERE条件用了多层嵌套CASE表达式，这会让SQL Server的查询优化器无法有效解析出可利用Name非聚集索引的逻辑，同时两种ORDER BY的选择要么结果错误，要么成本过高：

• 按Id, Name排序：直接走聚集索引，但Guid聚集索引本身无序，导致最终结果里Name无法按升序排列，结果不符合预期；
• 按Name, Id排序：虽然结果正确，但因为原WHERE条件的复杂性，优化器需要额外的回表或键查找操作，导致执行成本偏高。

优化步骤 #

1. 简化WHERE条件，还原逻辑

原CASE嵌套的逻辑可以等价改写为简单的布尔表达式，去掉所有CASE：

[c].[IsDeleted] = CAST(0 AS bit) 
AND [c].[Name] >= @__p_0 
AND (
    [c].[Name] > @__p_0 
    OR ([c].[Name] = @__p_1 AND [c].[Id] > @__p_2)
)

注意到你的@__p_0和@__p_1是同一个值，这个改写完全等价于原条件，但优化器能直接识别出这是基于Name的范围查询，能更好地利用Name的非聚集索引。

2. 创建覆盖索引，避免回表

因为你的查询只需要Id、Name，且WHERE里用到IsDeleted，直接创建一个包含所有所需列的非聚集索引：

CREATE NONCLUSTERED INDEX IX_Company_Name_Id_IsDeleted 
ON [Company] ([Name], [Id])
INCLUDE ([IsDeleted]);

这个索引的键列顺序刚好匹配ORDER BY [Name], [Id]，同时包含IsDeleted，查询时可以直接从索引里获取所有需要的数据，不需要回表访问聚集索引，大幅减少IO开销。

3. 使用匹配索引顺序的ORDER BY

保持ORDER BY [Name], [Id]，因为这和覆盖索引的键顺序完全一致，优化器可以直接利用索引的有序性返回结果，不需要额外的排序操作，进一步降低执行成本。

优化后的完整查询 #

exec sp_executesql N'SELECT TOP(@__p_3) [c].[Id], [c].[Name]
FROM [Company] AS [c]
WHERE [c].[IsDeleted] = CAST(0 AS bit) 
AND [c].[Name] >= @__p_0 
AND (
    [c].[Name] > @__p_0 
    OR ([c].[Name] = @__p_1 AND [c].[Id] > @__p_2)
)
ORDER BY [c].[Name], [c].[Id]',
N'@__p_3 int,@__p_0 nvarchar(300),@__p_1 nvarchar(300),@__p_2 uniqueidentifier',
@__p_3=3,
@__p_0=N'Salmaan and CO',
@__p_1=N'Salmaan and CO',
@__p_2='04D3EEC3-2A91-42E2-3463-08DADF2F5363'

为什么这样有效？ #

• 简化后的WHERE条件让优化器能直接识别出基于Name的范围查询逻辑，不会因为复杂CASE表达式放弃使用非聚集索引；
• 覆盖索引包含了查询所需的所有列，避免了回表操作，这是降低执行成本的关键；
• ORDER BY与索引键顺序匹配，优化器可以直接利用索引的有序结果，省去了额外的Sort运算符开销。

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