使用索引快速排序查询，但添加 where 子句时速度较慢答案

【问题标题】：Ordered query fast with index but slow when I add a where clause使用索引快速排序查询，但添加 where 子句时速度较慢
【发布时间】：2023-04-05 23:34:01
【问题描述】：

我有这个问题

SELECT [f].[Id], [f].[Code], [f0].[Path]
FROM [FunctionalAssets] AS [f]
INNER JOIN FunctionalAssetStructurePath AS [f0] ON f.Id = f0.FunctionalAssetId
WHERE [f0].[StructureConfigurationId] = 'A8A41B14-0A35-45D3-2A2B-08D904A3CD0B'
ORDER BY [f0].[Path], [f0].[Name]
OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY

我在表 FunctionalAssetStructurePath 上创建了一个索引，其中包含以下列：结构配置 ID、路径和名称。这个查询很快（100ms），没问题。

但是当我有这个查询时：

SELECT [f].[Id], [f].[Code], [f0].[Path]
FROM [FunctionalAssets] AS [f]
INNER JOIN FunctionalAssetStructurePath AS [f0] ON f.Id = f0.FunctionalAssetId
INNER JOIN FunctionalAssetStructure AS [f1] ON f.Id = f1.FunctionalAssetId
WHERE [f0].[StructureConfigurationId] = 'A8A41B14-0A35-45D3-2A2B-08D904A3CD0B'
    AND [f1].[StructureId] = 'ec40fc59-13e3-4e32-7290-08d90639e607'
ORDER BY [f0].[Path], [f0].[Name]
OFFSET 0 ROWS FETCH NEXT 100 ROWS ONLY

查询非常慢（+2000 毫秒）。

如果我删除索引，第一个查询很慢（+2000 毫秒），但第二个查询很快（200 毫秒）。

我觉得这很奇怪。你知道为什么吗？又该如何解决呢？

更新 1

Image with my index

谢谢

【问题讨论】：

您使用的是什么 DBMS？执行计划向您展示了什么？（顺便说一句，您应该花更多的精力来选择表别名；f 和 f0 在您尝试阅读代码时是不好的选择，尤其是当您像这里的读者一样不熟悉它时。）
另外，第二个查询在两个单独的表（f0 和f1）中包含两个匹配条件，其中第一个查询只需匹配单个表中的一个条件。第二个显然需要做更多的工作。
@KenWhite 我从实体框架复制了查询，这就是为什么我有别名 f 和 f0。问题出在过滤器上。在第一个查询中，我有 2M+ 项需要排序，而且速度很快（感谢索引）。在第二个查询中，过滤器返回 70 000 个项目并且速度很慢（但如果我删除索引它很快）。在这两种情况下，如果我将“order by path, name”更改为“order by (select 1)”，查询速度很快。所以问题是（我认为）的顺序。

标签： sql sql-order-by where-clause non-clustered-index

【解决方案1】：

对于您的第一个查询，您甚至没有从 FunctionalAssetStructure 表中提取任何值，那么您为什么要加入它。我会完全删除它

另外，如果您的过滤基于内部连接表，我会交换布局以提高表优先级的可读性。两个查询的流程相似，只需将辅助 AND 子句添加到其 INNER JOIN 的位置

为了更好地优化这个查询，我会确保你在表上有以下索引并且在提供的列顺序中

Table                          Index
FunctionalAssetStructurePath   ( StructureConfigurationId, [Path], Name )
FunctionalAssets               ( id, code )
FunctionalAssetStructure       ( FunctionalAssetId, StructureID )

用更有意义的别名重写以匹配表上下文

SELECT 
        fa.Id, 
        fa.Code, 
        fasp.[Path]
    FROM 
        FunctionalAssetStructurePath fasp
            INNER JOIN FunctionalAssets fa
                ON fasp.FunctionalAssetId = fa.Id
            INNER JOIN FunctionalAssetStructure fas
                ON fasp.FunctionalAssetId = fas.FunctionalAssetId
                AND fas.StructureId = 'ec40fc59-13e3-4e32-7290-08d90639e607'
    WHERE 
        fasp.StructureConfigurationId = 'A8A41B14-0A35-45D3-2A2B-08D904A3CD0B'
    ORDER BY 
        fasp.[Path], 
        fasp.Name
    OFFSET 
        0 ROWS 
    FETCH 
        NEXT 100 ROWS ONLY

同样，第一个查询从不需要对 FunctionalAssetStructure 表的附加联接，并且可能已被删除，但是通过附加 JOIN 条件（从 where 移动到 INNER JOIN），您可以看到索引有助于优化该组件。如果这有很大帮助，很高兴知道您的最终查询速度。

【讨论】：

对于第一个查询，这是一个错误的复制/粘贴。在我的场景中，FunctionalAssetStructure INNER JOIN 不存在。我确认我有提到的索引（以相同的顺序）。奇怪的是，在第一个查询中，我必须对 +200 万个项目进行排序，而且速度很快（感谢带有路径和名称列的索引）。在第二个查询中，过滤器返回 70 000 个项目，因此只需要对 70 000 个项目进行排序，而且速度很慢。但是，如果我删除索引（带有路径和名称列），查询会很快。如果我用“order (select 1)”更改顺序，这两个查询很快。
@KoosMos，这听起来像 FunctionalAssetStructurePath 表没有索引（ StructureConfigurationId, [Path], Name ）。单个多字段索引。这应该几乎立即返回，因为 WHERE 在 StructureConfigurationID 上，并且路径/名称也已经按照顺序进行了排序。由于是覆盖索引，因此它永远不必去数据页面寻找其他任何东西并快速解决。请确认索引包含所有 3 列，而不是每个索引 3 个单独的索引，而是 1 个包含所有 3 列的单个索引。
我确认我有一个包含这 3 列的索引（我更新了我的帖子）
@KoosMos，您更新的帖子仅表明您的索引在帖子和名称上，而不是 StructureConfigurationId、帖子和名称，所有 3 列对性能至关重要。第一列限定 WHERE，其余 2 列用于优化 ORDER by 子句。
如果你打开我帖子里的图片。你会看到我有 3 列。