sql-server - TSQL - 检查多条记录的最快方法是什么？

Question

有时我需要检查是否至少存在一条记录，通常我使用:

IF EXISTS (SELECT TOP 1 1 FROM [SomeTable] WHERE [Fields] = [Values]) BEGIN
-- action
END

是否有一种快速方法来检查是否存在多个记录？我可以做这样的事情:

IF EXISTS (SELECT 1 FROM [SomeTable] 
                        WHERE [Fields] = [Values] 
                                HAVING Count(*) > 1) 
BEGIN
    -- action
END

但我不确定这是否是最快的方法，因为它将测试集合中的所有记录。有没有更快的方法？

“where”部分可能非常复杂，可能由多个 AND 和 OR 组成。

Answer 1

SQL Server 通常不会短路聚合查询。有时，它可以将 HAVING COUNT(*) > 0 查询转换为使用与 EXISTS ( discussed in the comments here ) 相同的计划，但仅此而已。

HAVING COUNT(*) > 1 查询将始终对所有行进行计数，即使理论上它可能会在第 2 行之后停止计数。

考虑到这一点，我会使用

IF EXISTS(
  SELECT * FROM (
                 SELECT TOP 2 *
                 FROM [SomeTable] 
                 WHERE [Fields] = [Values] 
) T
HAVING COUNT(*)=2) 

TOP 2 迭代器将在第二个行返回后停止请求行，从而允许内部查询提前短路，而不是返回所有行并对其进行计数。

两个版本的示例计划如下

关于评论中的问题

"How can you tell which one is best? Is it the query cost?"

在计划中显示的特定情况下，上述成本将是一个合理的指示，因为估计和实际行计数非常准确，并且除了添加 TOP 迭代器之外，这两个计划非常相似。因此，计划中显示的额外成本完全代表了需要扫描(并且可能从光盘读入)和计数的额外行数这一事实。

在这种情况下，很明显，这只是额外的工作。在其他计划中可能并非如此。添加 TOP 2 可能会显着改变其下面的查询树(例如不喜欢 blocking iterators 的计划)

在这种情况下，执行计划中显示的成本可能不是可靠的指标。即使在实际执行计划中，显示的成本也是基于估计的，因此只能与估计的一样好，即使估计的行数很好，显示的成本仍然只是基于某些建模假设。

SQL Kiwi 在 this recent answer on the DBA site 中很好地说明了这一点

optimizer cost estimates are mainly only useful for internal server purposes. They are not intended to be used to assess potential performance, even at a 'high level'. The model is an abstraction that happens to work reasonably well for the internal purposes it was designed for. The chances that estimated costs bear any sensible resemblance to real execution costs on your hardware and configuration is very small indeed.

Choose other metrics to compare performance, based on whatever real issues are important to you.

逻辑读取(在SET STATISTICS IO ON;时显示)是一个可以查看的指标，但再次专门关注这一点可能会产生误导。测试查询持续时间可能是唯一可靠的方法，但即使这也不是一门精确的科学，因为性能可能会根据服务器上的并发事件(等待内存授予、可用的 DOP、缓存中的相关页面数量)而变化。

最终，归根结底就是获得一个能够有效利用服务器资源的查询计划。