为什么Index-seek是最昂贵的运营商，而不是此计划中的筛选器？ 阅读执行计划费用适当的时间

如何解决为什么Index-seek是最昂贵的运营商，而不是此计划中的筛选器？ 阅读执行计划费用适当的时间

我有此计划需要大约18秒钟来运行（由SentryOne计划资源管理器生成）：

Index-seek使用了非聚集索引，其中包含一些搜索谓词。 Filter运算符还有其他谓词，包括LIKE条件。

这是查询（种类）：

SELECT  TOP(20) *
FROM    Table
WHERE   Table.Col1 = ''
        AND Table.Col2 LIKE '%' + @searchString + '%'
ORDER BY Table.Col3

第一个（无关）问题：

您如何阅读执行计划？

在我读到它时，“ SQL”以最左边的运算符Top开头，然后将其右边的子运算符（节点）称为1行，并继续进行直到达到目标为止（ 20行）。如果没有Top，它将继续进行直到其子节点说没有剩余。子节点将调用子节点的子节点。因此，Filter调用了Index-seek达290万次，以获取上述计划中的290万行。我希望我是对的？

然后我对查询做了一个小改动：

SELECT  TOP(20) *
FROM    Table
WHERE   Col1 = ''
        AND Col2 LIKE @searchString + '%'  -- search for string prefix only
ORDER BY Table.Col3

这一次查询耗时不到2秒。实际执行与上面的完全相同。我比较了2个内部SSMS。 Index-seek仍然是最昂贵的运算符，但返回的行数相同（290万）。

第二个问题：

我在LIKE条件下所做的更改必须减少16s的执行时间。那么，为什么Index-seek被标记为最昂贵？难道不是Filter，因为它是处理LIKE搜索权的人吗？如果我不做这个实验，怎么知道LIKE条件在这里是邪恶的？

第三个问题：

我怎么知道SQL处理一个任务需要多少时间才算正确？

我问这个问题是因为我是优化查询的新手。我第一次看到该计划时，不知道在300万行上花费{18的Index-seek是正确的还是有问题。

解决方法

阅读执行计划

从右到左。 SQL Server创建一个执行计划，从右侧开始。 （数据所在的那一侧）

因此，在您的示例中，发生了索引查找，将N行数据流传输到左侧的下一个运算符，然后过滤器处理内存（页面缓冲区）中的所有行，依此类推。

要查看实际操作，可以在SSMS中打开live query statisitcs。这样，您可以看到流经每个运算符的数据。很高兴看到查询引擎正在运行。

费用

成本是相对的（基于estimated subtree cost）。从磁盘（SSD或HDD）中获取数据是I / O。 I / O仍然是一项昂贵的操作。您看到的index seek在从磁盘检索数据之前已经在照顾过滤器。否则，您将进行全表扫描或索引扫描。 可以将其视为电话簿：如果您按“姓氏”查找某个人，则可以跳过大部分页面，因为您知道该人姓名的首字母，并且该电话簿按字母顺序按姓名排序。

示例中的过滤器成本不高，因为所有行都在内存中并且索引搜索可能已经过滤掉了N行。

适当的时间

时间是相对的。取决于

• 硬件：SQL服务器上的查询可能需要16秒，但是在具有128 GB内存的计算机上运行该查询，而所有数据已经​​在缓冲池中，则可能需要不到100毫秒。
• 缓冲区缓存：所有数据或部分数据已经可以缓存在内存中
• 执行计划缓存：它是第一个执行（或OPTION(RECOMPILE)），然后SQL Server需要快速猜测最便宜的执行计划。该查询的第二次执行可以重用该计划，但是对于新传递的参数来说，它可能不是一个好的执行计划。
• 并行性：查询可以并行执行以减少总体执行时间，但增加CPU时间。取决于您的max degree of parallelism和cost threshold for parallelism
的内核和配置
• 索引碎片：当发生大量更新/删除时，索引可以碎片化。
• 统计信息：统计信息用于猜测将返回多少行，这种估算在许多情况下可能是错误的。 （统计信息不是最新的，索引中的数据种类繁多，201桶问题，...）
• 锁定和隔离级别：尝试读取数据时，可能有其他事务正在更改数据。锁定查询数据，增加执行时间。

如果您想要一个正确的比较编号，可以使用SET STATISTICS IO ON打开Statistics IO。如果您在运行查询后在SSMS中打开“邮件”标签，则会看到类似的内容。

Table 'Customer'. Scan count 1,logical reads 4152,physical reads 1,read-ahead reads 0,lob logical reads 0,lob physical reads 0,lob read-ahead reads 0.

逻辑读取是关键指标。它指示从中读取多少AK1 pages来创建所需的结果。

了解一个表（在聚集索引上）可以进行多少逻辑读取。您可以在统计信息IO处于打开状态的情况下执行简单的SELECT count(*) FROM table，然后将逻辑读取与查询进行比较。

当查询是非SARGABLE的（在您的示例LIKE '%' + @Param + '%'中）时，可能发生更多的逻辑读取，而表中却有页面。
如果查看电话簿示例，并且要检索姓氏包含“ Do”的所有人员，则需要扫描整本电话簿= nonSARGABLE。如果将其更改为开头，则可以进行索引查找，因为您知道Do的第一次出现在哪里，Dp的第一次出现在哪里。