小编Joe*_*ish的帖子

作为 ETL 过程的一部分，我们将暂存中的行与报告数据库进行比较，以确定自上次加载数据以来是否有任何列实际发生了更改。

比较基于表的唯一键和所有其他列的某种散列。我们目前使用HASHBYTES该SHA2_256算法，并发现如果许多并发工作线程都在调用HASHBYTES.

在 96 核服务器上进行测试时，以每秒哈希数衡量的吞吐量不会增加超过 16 个并发线程。我通过将并发MAXDOP 8查询的数量从 1更改为12 来进行测试。测试MAXDOP 1显示了相同的可扩展性瓶颈。

作为一种解决方法，我想尝试 SQL CLR 解决方案。这是我试图说明要求的尝试：

• 该函数必须能够参与并行查询
• 函数必须是确定性的
• 该函数必须接受一个NVARCHAR或VARBINARY字符串的输入（所有相关列都连接在一起）
• 字符串的典型输入大小为 100 - 20000 个字符。20000 不是最大值
• 哈希冲突的几率应该大致等于或优于 MD5 算法。CHECKSUM对我们不起作用，因为冲突太多。
• 该函数必须在大型服务器上很好地扩展（每个线程的吞吐量不应随着线程数量的增加而显着降低）

对于 Application Reasons™，假设我无法保存报告表的哈希值。这是一个不支持触发器或计算列的 CCI（还有其他我不想讨论的问题）。

HASHBYTES使用 SQL CLR 函数进行模拟的可扩展方式是什么？我的目标可以表示为在大型服务器上每秒获得尽可能多的哈希值，因此性能也很重要。我对 CLR 很糟糕，所以我不知道如何做到这一点。如果它激励任何人回答，我计划尽快为这个问题添加赏金。下面是一个示例查询，它非常粗略地说明了用例：

DROP TABLE IF EXISTS #CHANGED_IDS;

SELECT stg.ID INTO #CHANGED_IDS
FROM (
    SELECT ID,
    CAST( HASHBYTES ('SHA2_256', 
        CAST(FK1 AS NVARCHAR(19)) + 
        CAST(FK2 AS NVARCHAR(19)) …

目的

在尝试创建自引用函数的测试示例时，一个版本失败而另一个版本成功。

唯一的区别是添加SELECT到函数体导致两者的执行计划不同。

起作用的功能

CREATE FUNCTION dbo.test5(@i int)
RETURNS INT
AS 
BEGIN
RETURN(
SELECT TOP 1
CASE 
WHEN @i = 1 THEN 1
WHEN @i = 2 THEN 2
WHEN @i = 3 THEN  dbo.test5(1) + dbo.test5(2)
END
)
END;

调用函数

SELECT dbo.test5(3);

退货

(No column name)
3

不起作用的功能

CREATE FUNCTION dbo.test6(@i int)
RETURNS INT
AS 
BEGIN
RETURN(
SELECT TOP 1
CASE 
WHEN @i = 1 THEN 1
WHEN @i = 2 THEN 2
WHEN @i = 3 …

我能够重现一个我认为出乎意料的查询性能问题。我正在寻找一个专注于内部的答案。

在我的机器上，以下查询执行聚集索引扫描并花费大约 6.8 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test WITH (FORCESCAN)
WHERE ID1 NOT IN
(
N'1', N'2',N'3', N'4', N'5',
N'6', N'7', N'8', N'9', N'10',
N'11', N'12',N'13', N'14', N'15',
N'16', N'17', N'18', N'19', N'20'
)
AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT'))
ORDER BY ID1, ID2 OFFSET 12000000 ROWS FETCH FIRST 1 ROW ONLY
OPTION (MAXDOP 1);

以下查询执行聚集索引查找（唯一的区别是删除FORCESCAN提示），但需要大约 18.2 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test
WHERE ID1 …

我遇到了一些SELECT DISTINCT TOP N查询，这些查询似乎被 SQL Server 查询优化器优化得很差。让我们从一个简单的例子开始：具有两个交替值的百万行表。我将使用GetNums函数来生成数据：

DROP TABLE IF EXISTS X_2_DISTINCT_VALUES;

CREATE TABLE X_2_DISTINCT_VALUES (PK INT IDENTITY (1, 1), VAL INT NOT NULL);

INSERT INTO X_2_DISTINCT_VALUES WITH (TABLOCK) (VAL)
SELECT N % 2
FROM dbo.GetNums(1000000);

UPDATE STATISTICS X_2_DISTINCT_VALUES WITH FULLSCAN;

对于以下查询：

SELECT DISTINCT TOP 2 VAL
FROM X_2_DISTINCT_VALUES
OPTION (MAXDOP 1);

SQL Server 可以通过扫描表的第一个数据页找到两个不同的值，但它会扫描所有数据。为什么 SQL Server 不进行扫描，直到找到所需数量的不同值？

对于这个问题，请使用以下测试数据，其中包含 1000 万行，并在块中生成 10 个不同的值：

DROP TABLE IF EXISTS X_10_DISTINCT_HEAP;

CREATE TABLE X_10_DISTINCT_HEAP (VAL VARCHAR(10) NOT …

我正在尝试了解有关 SQL Server 2016 中引入的“外键引用检查”查询计划运算符的更多信息。关于它的信息并不多。微软在这里宣布了它，我在这里发表了关于它的博客。通过从具有 254 个或更多传入外键引用的父表中删除一行，可以看到新的运算符：dbfiddle link。

操作员详细信息中显示了三种不同的计数：

• 外键引用计数是传入外键的数量。
• No matching Indexes Count是没有合适索引的传入外键的数量。验证更新或删除的表不会违反该约束将需要扫描子表。
• 我不知道Partial Matching Indexes Count代表什么。

在这种情况下什么是部分匹配索引？我无法使以下任何一项工作：

• 过滤索引
• 将外键列作为INCLUDE索引列
• 以外键列作为第二键列的索引
• 多列外键的单列索引
• 创建多个覆盖索引以启用多列外键的“索引连接”计划

Dan Guzman指出，即使索引键与外键列的顺序不同，多列外键也可以匹配索引。他的代码在这里，以防有人能够使用它作为起点来找出更多关于部分匹配索引的信息。

考虑以下人为但简单的查询：

SELECT 
  ID
, CASE
    WHEN ID <> 0 
    THEN (SELECT TOP 1 ID FROM X_OTHER_TABLE) 
    ELSE (SELECT TOP 1 ID FROM X_OTHER_TABLE_2) 
  END AS ID2
FROM X_HEAP;

我希望此查询的最终行估计值等于X_HEAP表中的行数。无论我在子查询中做什么，对于行估计都无关紧要，因为它无法过滤掉任何行。但是，在 SQL Server 2016 上，由于子查询，我看到行估计值减少到 1：

为什么会发生这种情况？我该怎么办？

使用正确的语法很容易重现这个问题。这是一组可以执行此操作的表定义：

CREATE TABLE dbo.X_HEAP (ID INT NOT NULL)
CREATE TABLE dbo.X_OTHER_TABLE (ID INT NOT NULL);
CREATE TABLE dbo.X_OTHER_TABLE_2 (ID INT NOT NULL);

INSERT INTO dbo.X_HEAP WITH (TABLOCK)
SELECT TOP (1000) ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values;

CREATE STATISTICS X_HEAP__ID ON X_HEAP …

该sp_getapplock存储过程有以下返回值：

0：同步成功授予锁。
1：等待其他不兼容的锁释放后，成功授予锁。
-1：锁定请求超时。
-2：锁定请求被取消。
-3：锁定请求被选为死锁牺牲品。
-999：表示参数验证或其他调用错误。

我正在编写一个用于调用sp_getapplock我们的数据访问层的包装器，我想知道在什么情况下可以返回 -2，以便我可以抛出一个描述性和有用的异常。-1 和 -3 的返回值的含义很明显，我可以轻松创建导致返回这些值的测试条件。我将如何设法获得 -2 的返回值？

我一直在研究 SQL Server (2012) 上的统计更新的采样阈值，并注意到一些奇怪的行为。基本上，采样的行数在某些情况下似乎有所不同 - 即使是相同的数据集。

我运行这个查询：

--Drop table if exists
IF (OBJECT_ID('dbo.Test')) IS NOT NULL DROP TABLE dbo.Test;

--Create Table for Testing
CREATE TABLE dbo.Test(Id INT IDENTITY(1,1) CONSTRAINT PK_Test PRIMARY KEY CLUSTERED, TextValue VARCHAR(20) NULL);

--Insert enough data so we have more than 8Mb (the threshold at which sampling kicks in)
INSERT INTO dbo.Test(TextValue) 
SELECT TOP 1000000 'blahblahblah'
FROM sys.objects a, sys.objects b, sys.objects c, sys.objects d;  

--Create Index on TextValue
CREATE INDEX IX_Test_TextValue ON dbo.Test(TextValue);

--Update Statistics …

我问这个问题是为了更好地了解优化器的行为并了解索引假脱机的限制。假设我将 1 到 10000 之间的整数放入堆中：

CREATE TABLE X_10000 (ID INT NOT NULL);
truncate table X_10000;

INSERT INTO X_10000 WITH (TABLOCK)
SELECT TOP 10000 ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
FROM master..spt_values t1
CROSS JOIN master..spt_values t2;

并强制嵌套循环连接MAXDOP 1：

SELECT *
FROM X_10000 a
INNER JOIN X_10000 b ON a.ID = b.ID
OPTION (LOOP JOIN, MAXDOP 1);

这是对 SQL Server 采取的相当不友好的操作。当两个表都没有任何相关索引时，嵌套循环连接通常不是一个好的选择。这是计划：

在我的机器上查询需要 13 秒，从 table spool 中提取了 100000000 行。但是，我不明白为什么查询必须很慢。查询优化器能够通过索引假脱机动态创建索引。这个查询似乎是索引假脱机的完美候选者。

以下查询返回与第一个相同的结果，具有索引假脱机，并且在不到一秒的时间内完成：

SELECT *
FROM X_10000 a
CROSS APPLY …

以下 T-SQL 在我的机器上使用 SSMS v17.9 大约需要 25 秒：

DECLARE @outer_loop INT = 0,
@big_string_for_u VARCHAR(8000);

SET NOCOUNT ON;

WHILE @outer_loop < 50000000
BEGIN
    SET @big_string_for_u = 'ZZZZZZZZZZ';
    SET @outer_loop = @outer_loop + 1;
END;

它ASYNC_NETWORK_IO根据sys.dm_exec_session_wait_stats和累积了 532 毫秒的等待时间sys.dm_os_wait_stats。总等待时间随着循环迭代次数的增加而增加。使用wait_completed扩展事件，我可以看到等待大约每 43 毫秒发生一次，但有一些例外：

此外，我可以获得在ASYNC_NETWORK_IO等待之前发生的调用堆栈：

sqldk.dll!SOS_DispatcherBase::GetTrack+0x7f6c
sqldk.dll!SOS_Scheduler::PromotePendingTask+0x204
sqldk.dll!SOS_Task::PostWait+0x5f
sqldk.dll!SOS_Scheduler::Suspend+0xb15
sqllang.dll!CSECCNGProvider::GetBCryptHandleFromAlgID+0xf6af
sqllang.dll!CSECCNGProvider::GetBCryptHandleFromAlgID+0xf44c
sqllang.dll!SNIPacketRelease+0xd63
sqllang.dll!SNIPacketRelease+0x2097
sqllang.dll!SNIPacketRelease+0x1f99
sqllang.dll!SNIPacketRelease+0x18fe
sqllang.dll!CAutoExecuteAsContext::Restore+0x52d
sqllang.dll!CSQLSource::Execute+0x151b
sqllang.dll!CSQLSource::Execute+0xe13
sqllang.dll!CSQLSource::Execute+0x474
sqllang.dll!SNIPacketRelease+0x165d
sqllang.dll!CValOdsRow::CValOdsRow+0xa92
sqllang.dll!CValOdsRow::CValOdsRow+0x883
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x15d
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x638
sqldk.dll!ClockHand::Statistic::RecordClockHandStats+0x2ad
sqldk.dll!SystemThread::MakeMiniSOSThread+0xdf8
sqldk.dll!SystemThread::MakeMiniSOSThread+0xf00
sqldk.dll!SystemThread::MakeMiniSOSThread+0x667
sqldk.dll!SystemThread::MakeMiniSOSThread+0xbb9

最后，我注意到 SSMS 在循环期间使用了惊人数量的 CPU（平均大约一半内核）。我无法弄清楚 SSMS 在那段时间在做什么。 …