单行INSERT…SELECT比单独的SELECT慢得多

给定以下堆表，该堆表具有从1到400编号的400行：

DROP TABLE IF EXISTS dbo.N;
GO
SELECT 
    SV.number
INTO dbo.N 
FROM master.dbo.spt_values AS SV
WHERE 
    SV.[type] = N'P'
    AND SV.number BETWEEN 1 AND 400;

以及以下设置：

SET NOCOUNT ON;
SET STATISTICS IO, TIME OFF;
SET STATISTICS XML OFF;
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;

以下SELECT语句将在6秒钟左右完成（demo，plan）：

DECLARE @n integer = 400;

SELECT
    c = COUNT_BIG(*) 
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE 
    N.number <= @n
    AND N2.number <= @n
    AND N3.number <= @n
OPTION
    (OPTIMIZE FOR (@n = 1));

_{注意：@该OPTIMIZE FOR子句仅是为了生成合理大小的repro，以捕获实际问题的基本细节，包括可能由于多种原因而引起的基数错误估计。}

将单行输出写入表时，需要19秒（demo，plan）：

DECLARE @T table (c bigint NOT NULL);

DECLARE @n integer = 400;

INSERT @T
    (c)
SELECT
    c = COUNT_BIG(*) 
FROM dbo.N AS N
CROSS JOIN dbo.N AS N2
CROSS JOIN dbo.N AS N3
WHERE 
    N.number <= @n
    AND N2.number <= @n
    AND N3.number <= @n
OPTION
    (OPTIMIZE FOR (@n = 1));

除了插入一行外，执行计划看起来是相同的。

所有额外的时间似乎都被CPU占用了。

为什么INSERT声明这么慢？

SQL Server选择使用行级锁扫描循环联接内侧的堆表。完全扫描通常会选择页面级别的锁定，但是表大小和谓词的组合意味着存储引擎选择行锁定，因为这似乎是最便宜的策略。

基数misestimation故意引入的OPTIMIZE FOR装置，所述堆被扫描许多比优化希望更多倍，并且它不引入卷轴，因为它通常会。

这些因素的组合意味着性能对运行时所需的锁数非常敏感。

该SELECT语句受益于优化，该优化允许在不存在读取未提交数据的危险且不存在行外数据的情况下跳过行级共享锁（仅获取意图共享的页级锁）。

该INSERT...SELECT语句没有从这种优化中受益，因此在第二种情况下，每秒获取和释放数百万个RID锁以及意图共享的页面级锁。

大量的锁定活动占用了额外的CPU和经过的时间。

最自然的解决方法是确保优化器（和存储引擎）获得合理的基数估计，以便他们做出正确的选择。

如果在实际用例中不可行，则可以将INSERTand SELECT语句分开，并将结果SELECT保存在变量中。这将使该SELECT语句受益于锁跳过优化。

更改隔离级别也可以通过不使用共享锁或确保锁升级迅速进行来实现。

最后一个有趣的问题是，SELECT通过使用未记录的跟踪标志8691强制使用线轴，可以使查询比优化的情况运行得更快。