it-swarm.com.de

Warum ist ein Scan schneller als die Suche nach diesem Prädikat?

Ich konnte ein Problem mit der Abfrageleistung reproduzieren, das ich als unerwartet beschreiben würde. Ich suche nach einer Antwort, die sich auf Interna konzentriert.

Auf meinem Computer führt die folgende Abfrage einen Clustered-Index-Scan durch und benötigt ca. 6,8 Sekunden CPU-Zeit:

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);

Die folgende Abfrage führt eine Clustered-Index-Suche durch (der einzige Unterschied besteht darin, den Hinweis FORCESCAN zu entfernen), benötigt jedoch ungefähr 18,2 Sekunden CPU-Zeit:

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);

Die Abfragepläne sind ziemlich ähnlich. Für beide Abfragen werden 120000001 Zeilen aus dem Clustered-Index gelesen:

(query plans

Ich bin auf SQL Server 2017 CU 10. Hier ist Code zum Erstellen und Auffüllen des two_col_key_test Tabelle:

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;

Ich hoffe auf eine Antwort, die mehr kann als nur das Stack-Reporting. Zum Beispiel kann ich sehen, dass sqlmin!TCValSSInRowExprFilter<231,0,0>::GetDataX benötigt in der langsamen Abfrage deutlich mehr CPU-Zyklen als in der schnellen:

(perview

Anstatt dort anzuhalten, möchte ich verstehen, was das ist und warum es einen so großen Unterschied zwischen den beiden Abfragen gibt.

Warum gibt es für diese beiden Abfragen einen großen Unterschied in der CPU-Zeit?

30
Joe Obbish

Warum gibt es für diese beiden Abfragen einen großen Unterschied in der CPU-Zeit?

Der Scanplan wertet für jede Zeile das folgende Push-nicht-sargable (Rest-) Prädikat aus:

[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

Der Suchplan führt zwei Suchoperationen durch:

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')

... um diesem Teil des Prädikats zu entsprechen:

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

Ein Restprädikat wird auf Zeilen angewendet, die die oben genannten Suchbedingungen erfüllen (alle Zeilen in Ihrem Beispiel).

Jede Ungleichung wird jedoch durch zwei separate Tests für kleiner alsOR größer als ersetzt:

([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

Umschreiben jeder Ungleichung, z.

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

... ist hier kontraproduktiv. Kollatierungsbewusste Zeichenfolgenvergleiche sind teuer. Das Verdoppeln der Anzahl der Vergleiche erklärt den größten Unterschied in der CPU-Zeit.

Sie können dies deutlicher sehen, indem Sie das Pushing von nicht sargierbaren Prädikaten mit dem undokumentierten Trace-Flag 9130 deaktivieren. Dadurch wird der Rest als separater Filter mit Leistungsinformationen angezeigt, die Sie separat überprüfen können:

(scan

(seek

Dies wird auch die leichte Kardinalitätsfehlschätzung bei der Suche hervorheben, was erklärt, warum der Optimierer die Suche überhaupt über den Scan gewählt hat (er erwartete, dass der Suchabschnitt einige Zeilen eliminiert).

Während das Umschreiben der Ungleichung einen (möglicherweise gefilterten) Indexabgleich ermöglichen kann (um die Suchfähigkeit von B-Baum-Indizes bestmöglich zu nutzen), ist es besser, diese Erweiterung anschließend zurückzusetzen, wenn beide Hälften im Residuum enden. Sie können dies als Verbesserung der SQL Server-Feedback-Site vorschlagen.

Beachten Sie auch, dass das ursprüngliche ("Legacy") Kardinalitätsschätzungsmodell standardmäßig einen Scan für diese Abfrage auswählt.

32
Paul White 9