web-dev-qa-db-ja.com

スキャンがこの述語を探すよりも速いのはなぜですか？

予想外のクエリパフォーマンスの問題を再現できました。内部に焦点を当てた答えを探しています。

私のマシンでは、次のクエリがクラスター化インデックススキャンを実行し、約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ヒントを削除しているだけです）が、CPU時間は約18.2秒かかります。

SELECT ID1, ID2
FROM two_col_key_test
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);

クエリプランはかなり似ています。どちらのクエリでも、クラスター化インデックスから120000001行が読み取られます。

query plans

私はSQL Server 2017 CU 10を使用しています。以下は、two_col_key_testテーブルを作成してデータを設定するコードです。

drop table if exists dbo.two_col_key_test;

CREATE TABLE dbo.two_col_key_test (
    ID1 NVARCHAR(50) NOT NULL,
    ID2 NVARCHAR(50) NOT NULL,
    FILLER NVARCHAR(50),
    PRIMARY KEY (ID1, ID2)
);

DROP TABLE IF EXISTS #t;

SELECT TOP (4000) 0 ID INTO #t
FROM master..spt_values t1
CROSS JOIN master..spt_values t2
OPTION (MAXDOP 1);


INSERT INTO dbo.two_col_key_test WITH (TABLOCK)
SELECT N'FILLER TEXT' + CASE WHEN ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) > 8000000 THEN N' 2' ELSE N'' END
, ROW_NUMBER() OVER (ORDER BY (SELECT NULL))
, NULL
FROM #t t1
CROSS JOIN #t t2;

コールスタックレポート以上のことを行う回答を期待しています。たとえば、速いクエリと比較して、遅いクエリではsqlmin!TCValSSInRowExprFilter<231,0,0>::GetDataXのCPUサイクルが大幅に増えることがわかります。

perview

そこで停止するのではなく、それが何であるか、および2つのクエリの間にこのような大きな違いがある理由を理解したいと思います。

これら2つのクエリのCPU時間に大きな違いがあるのはなぜですか？

sql-serverperformancedatabase-internalsquery-performance
30
Joe Obbish

これら2つのクエリのCPU時間に大きな違いがあるのはなぜですか？

スキャンプランは、各行に対して次のプッシュされた検索不可（残差）述語を評価します。

[two_col_key_test].[ID1]<>N'1' 
AND [two_col_key_test].[ID1]<>N'10' 
AND [two_col_key_test].[ID1]<>N'11' 
AND [two_col_key_test].[ID1]<>N'12' 
AND [two_col_key_test].[ID1]<>N'13' 
AND [two_col_key_test].[ID1]<>N'14' 
AND [two_col_key_test].[ID1]<>N'15' 
AND [two_col_key_test].[ID1]<>N'16' 
AND [two_col_key_test].[ID1]<>N'17' 
AND [two_col_key_test].[ID1]<>N'18' 
AND [two_col_key_test].[ID1]<>N'19' 
AND [two_col_key_test].[ID1]<>N'2' 
AND [two_col_key_test].[ID1]<>N'20' 
AND [two_col_key_test].[ID1]<>N'3' 
AND [two_col_key_test].[ID1]<>N'4' 
AND [two_col_key_test].[ID1]<>N'5' 
AND [two_col_key_test].[ID1]<>N'6' 
AND [two_col_key_test].[ID1]<>N'7' 
AND [two_col_key_test].[ID1]<>N'8' 
AND [two_col_key_test].[ID1]<>N'9' 
AND 
(
    [two_col_key_test].[ID1]=N'FILLER TEXT' 
    AND [two_col_key_test].[ID2]>=N'' 
    OR [two_col_key_test].[ID1]>N'FILLER TEXT'
)

scan residual

シーク計画は、2つのシーク操作を実行します。

Seek Keys[1]: 
    Prefix: 
    [two_col_key_test].ID1 = Scalar Operator(N'FILLER TEXT'), 
        Start: [two_col_key_test].ID2 >= Scalar Operator(N'')
Seek Keys[1]: 
    Start: [two_col_key_test].ID1 > Scalar Operator(N'FILLER TEXT')

...述語のこの部分に一致させるには：

(ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT'))

残余述語は、上記のシーク条件を通過する行（例ではすべての行）に適用されます。

ただし、各不等式は、less thanORgreater than：

([two_col_key_test].[ID1]<N'1' OR [two_col_key_test].[ID1]>N'1') 
AND ([two_col_key_test].[ID1]<N'10' OR [two_col_key_test].[ID1]>N'10') 
AND ([two_col_key_test].[ID1]<N'11' OR [two_col_key_test].[ID1]>N'11') 
AND ([two_col_key_test].[ID1]<N'12' OR [two_col_key_test].[ID1]>N'12') 
AND ([two_col_key_test].[ID1]<N'13' OR [two_col_key_test].[ID1]>N'13') 
AND ([two_col_key_test].[ID1]<N'14' OR [two_col_key_test].[ID1]>N'14') 
AND ([two_col_key_test].[ID1]<N'15' OR [two_col_key_test].[ID1]>N'15') 
AND ([two_col_key_test].[ID1]<N'16' OR [two_col_key_test].[ID1]>N'16') 
AND ([two_col_key_test].[ID1]<N'17' OR [two_col_key_test].[ID1]>N'17') 
AND ([two_col_key_test].[ID1]<N'18' OR [two_col_key_test].[ID1]>N'18') 
AND ([two_col_key_test].[ID1]<N'19' OR [two_col_key_test].[ID1]>N'19') 
AND ([two_col_key_test].[ID1]<N'2' OR [two_col_key_test].[ID1]>N'2') 
AND ([two_col_key_test].[ID1]<N'20' OR [two_col_key_test].[ID1]>N'20') 
AND ([two_col_key_test].[ID1]<N'3' OR [two_col_key_test].[ID1]>N'3') 
AND ([two_col_key_test].[ID1]<N'4' OR [two_col_key_test].[ID1]>N'4') 
AND ([two_col_key_test].[ID1]<N'5' OR [two_col_key_test].[ID1]>N'5') 
AND ([two_col_key_test].[ID1]<N'6' OR [two_col_key_test].[ID1]>N'6') 
AND ([two_col_key_test].[ID1]<N'7' OR [two_col_key_test].[ID1]>N'7') 
AND ([two_col_key_test].[ID1]<N'8' OR [two_col_key_test].[ID1]>N'8') 
AND ([two_col_key_test].[ID1]<N'9' OR [two_col_key_test].[ID1]>N'9')

seek residual

各不等式を書き換えます。例：

[ID1] <> N'1'  ->  [ID1]<N'1' OR [ID1]>N'1'

...ここでは逆効果です。照合対応の文字列比較は高価です。比較の数を2倍にすると、CPU時間の違いのほとんどがわかります。

ドキュメント化されていないトレースフラグ9130を使用して、引数を指定できない述語のプッシュを無効にすることで、これをより明確に確認できます。これにより、残差が個別のフィルターとして表示され、パフォーマンス情報を個別に検査できます。

scan

seek

これはまた、シークのわずかなカーディナリティの誤解を強調します。これは、オプティマイザが最初にスキャンよりもシークを選択した理由を説明します（シーク部分が一部の行を削除することを期待していました）。

不等式の書き換えにより、インデックスのマッチングが可能になります（フィルター処理される可能性があります）（Bツリーインデックスのシーク機能を最大限に活用するため）。 SQL Serverフィードバックサイト の改善としてこれを提案できます。

また、元の（「レガシー」）カーディナリティ推定モデルでは、このクエリに対してデフォルトでスキャンが選択されることにも注意してください。

32
Paul White 9