इस विधेय के लिए खोज की तुलना में तेजी से स्कैन क्यों किया जाता है?

Question

मैं एक क्वेरी प्रदर्शन समस्या को पुन: उत्पन्न करने में सक्षम था जिसे मैं अप्रत्याशित रूप से वर्णित करूंगा। मैं एक ऐसे उत्तर की तलाश कर रहा हूं जो इंटर्नल पर केंद्रित हो।

मेरी मशीन पर, निम्नलिखित क्वेरी एक क्लस्टर इंडेक्स स्कैन करती है और CPU समय के बारे में 6.8 सेकंड लेती है:

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 पंक्तियाँ पढ़ी जाती हैं:

मैं 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 चक्र लगते हैं:

वहाँ रुकने के बजाय, मैं यह समझना चाहता हूँ कि ऐसा क्या है और दोनों प्रश्नों के बीच इतना बड़ा अंतर क्यों है।

इन दो प्रश्नों के लिए CPU समय में बड़ा अंतर क्यों है?

Answer 1

इन दो प्रश्नों के लिए 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'
)

तलाश योजना दो संचालन की मांग करती है:

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

एक अवशिष्ट विधेय को उन पंक्तियों पर लागू किया जाता है जो ऊपर दी गई शर्तों को पार करती हैं (आपके उदाहरण में सभी पंक्तियाँ)।

हालांकि, प्रत्येक असमानता को दो अलग-अलग परीक्षणों से कम से कम के लिए बदल दिया जाता OR है :

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

प्रत्येक असमानता को पुनर्जीवित करना जैसे:

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

... यहाँ प्रतिप्रश्न है। कॉलेशन-जागरूक स्ट्रिंग तुलना महंगी है। तुलनाओं की संख्या को दोगुना करना आपके द्वारा देखे गए सीपीयू समय के अधिकांश अंतर को स्पष्ट करता है।

आप इसे अनिर्दिष्ट ट्रेस फ़्लैग 9130 के साथ नॉन-सर्जेबल विधेयकों के धकेलने को अक्षम करके अधिक स्पष्ट रूप से देख सकते हैं। यह अवशिष्ट को एक अलग फ़िल्टर के रूप में दिखाएगा, प्रदर्शन जानकारी के साथ आप अलग से निरीक्षण कर सकते हैं:

यह चाहने वाले पर थोड़ी कार्डिनैलिटी की गलतफहमी को भी उजागर करेगा, जो बताता है कि ऑप्टिमाइज़र ने पहली बार में स्कैन पर तलाश को क्यों चुना (यह कुछ पंक्तियों को खत्म करने के लिए मांग वाले हिस्से की उम्मीद करता है)।

हालांकि असमानता फिर से लिख सकती है (संभवतः फ़िल्टर्ड) इंडेक्स का मिलान संभव है (बी-ट्री इंडेक्स की मांग की क्षमता का सबसे अच्छा उपयोग करने के लिए), यह बेहतर होगा कि बाद में इस विस्तार को वापस कर दिया जाए अगर दोनों अवशिष्ट अवशिष्ट में समाप्त हो जाते हैं। आप SQL सर्वर प्रतिक्रिया साइट पर सुधार के रूप में यह सुझाव दे सकते हैं ।

यह भी ध्यान दें कि मूल ("विरासत") कार्डिनैलिटी अनुमान मॉडल इस क्वेरी के लिए डिफ़ॉल्ट रूप से एक स्कैन का चयन करने के लिए होता है।