LIKE ऑपरेटर के लिए कार्डिनैलिटी का अनुमान (स्थानीय चर)


24

मैं इस धारणा के तहत था कि जब LIKEसभी परिदृश्यों में ऑपरेटर का उपयोग करते हुए दोनों विरासत और नए सीईएस 9% अनुमान का उपयोग करते हैं (यह मानते हुए कि प्रासंगिक आँकड़े उपलब्ध हैं और क्वेरी ऑप्टिमाइज़र को चयनात्मकता अनुमानों का सहारा नहीं लेना है)।

क्रेडिट डेटाबेस के खिलाफ नीचे की क्वेरी निष्पादित करते समय मुझे अलग-अलग सीई के तहत अलग-अलग अनुमान मिलते हैं। नए CE के तहत मुझे 900 पंक्तियों का अनुमान प्राप्त होता है जिसकी मुझे उम्मीद थी, विरासत CE के तहत मुझे 241.416 का अनुमान प्राप्त होता है और मैं यह अनुमान नहीं लगा सकता कि यह अनुमान कैसे लगाया जाता है। क्या कोई भी प्रकाश को बहा सकता है?

-- New CE (Estimate = 900)
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM [Credit].[dbo].[member]
WHERE [lastname] LIKE @LastName;

-- Forcing Legacy CE (Estimate = 241.416)
DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM [Credit].[dbo].[member]
WHERE [lastname] LIKE @LastName
OPTION (
QUERYTRACEON 9481,
QUERYTRACEON 9292,
QUERYTRACEON 9204,
QUERYTRACEON 3604
);

मेरे परिदृश्य में, मेरे पास पहले से ही संगतता स्तर 120 के लिए क्रेडिट डेटाबेस सेट है, इसलिए दूसरी क्वेरी में मैं विरासत सीई का उपयोग करने के लिए ट्रेस झंडे का उपयोग कर रहा हूं और क्वेरी ऑप्टिमाइज़र द्वारा उपयोग किए गए / विचार किए गए आंकड़ों के बारे में भी जानकारी प्रदान कर सकता हूं। मैं देख सकता हूं कि 'lastname' पर कॉलम के आँकड़े का उपयोग किया जा रहा है, लेकिन मैं अभी भी काम नहीं कर पा रहा हूँ कि 241.416 का अनुमान कैसे निकाला जाता है।

मुझे इस इत्ज़िक बेन-गान लेख के अलावा और कुछ भी ऑनलाइन नहीं मिला , जिसमें कहा गया है "जब सभी परिदृश्यों में LIKE विधेय का उपयोग करते हैं तो दोनों विरासत और नए CE 9 प्रतिशत अनुमान का उपयोग करते हैं।" उस पोस्ट की जानकारी गलत प्रतीत होगी।

जवाबों:


28

LIKE आपके मामले का अनुमान इस पर आधारित है:

  • G: मानक 9% अनुमान ( sqllang!x_Selectivity_Like)
  • M: 6 का कारक (जादू की संख्या)
  • D: बाइट्स (आँकड़ों से) में औसत डेटा लंबाई, पूर्णांक तक गोल

विशेष रूप से, sqllang!CCardUtilSQL7::ProbLikeGuessउपयोग करता है:

Selectivity (S) = G / M * LOG(D)

टिप्पणियाँ:

  • LOG(D)यदि D1 और 2 के बीच है तो यह शब्द छोड़ा गया है।
  • यदि D1 से कम है (लापता या NULLसांख्यिकी के लिए):
    D = FLOOR(0.5 * maximum column byte length)

इस प्रकार की चतुराई और जटिलता मूल सीई के लिए काफी विशिष्ट है।

प्रश्न के उदाहरण में, औसत लंबाई 5 है ( DBCC SHOW_STATISTICSनीचे से 5.6154 ):

अनुमान = १०,००० * (०.० ९ / ६ * लॉग (५)) = २४१.४१६

अन्य उदाहरण मूल्य:

 डी   = एस के लिए सूत्र का उपयोग कर अनुमान
 15 = 406.208
 14 = 395.859
 13 = 384.742
 12 = 372.736
 11 = 359.684
 10 = 345.388
 09 = 329.584
 08 = 311.916
 07 = 291.887
 06 = 268.764
 05 = 241.416
 04 = 207.944
 03 = 164.792
 02 = 150.000 (लॉग का उपयोग नहीं किया गया)
 01 = 150.000 (लॉग का उपयोग नहीं किया गया)
 00 = 291.887 (लॉग 7) / * FLOOR (0.5 * 15) [15 के बाद से lastname varchar (15)] * / है

टेस्ट रिग

DECLARE
    @CharLength integer = 5, -- Set length here
    @Counter integer = 1;

CREATE TABLE #T (c1 varchar(15) NULL);

-- Add 10,000 rows
SET NOCOUNT ON;
SET STATISTICS XML OFF;

BEGIN TRANSACTION;
WHILE @Counter <= 10000
BEGIN
    INSERT #T (c1) VALUES (REPLICATE('X', @CharLength));
    SET @Counter = @Counter + 1;
END;
COMMIT TRANSACTION;

SET NOCOUNT OFF;
SET STATISTICS XML ON;

-- Test query
DECLARE @Like varchar(15);
SELECT * FROM #T AS T 
WHERE T.c1 LIKE @Like;

DROP TABLE #T;

15

मैंने SQL सर्वर 2014 पर विरासत CE के साथ परीक्षण किया और कार्डिनैलिटी अनुमान के रूप में 9% नहीं मिला। मुझे कुछ भी सटीक ऑनलाइन नहीं मिल रहा था इसलिए मैंने कुछ परीक्षण किया और मुझे एक मॉडल मिला जो सभी परीक्षण मामलों में फिट बैठता है जो मैंने कोशिश की थी, लेकिन मुझे यकीन नहीं है कि यह पूरा हो गया है।

मुझे जो मॉडल मिला, उसका अनुमान तालिका में पंक्तियों की संख्या, फ़िल्टर्ड कॉलम के आँकड़ों की औसत कुंजी लंबाई और कभी-कभी फ़िल्टर्ड कॉलम की डेटापाइप लंबाई से लिया गया है। अनुमान के लिए उपयोग किए जाने वाले दो अलग-अलग सूत्र हैं।

यदि FLOOR (औसत कुंजी लंबाई) = 0 तो अनुमान सूत्र स्तंभ के आँकड़ों की उपेक्षा करता है और डेटाटाइप लंबाई के आधार पर एक अनुमान बनाता है। मैंने केवल VARCHAR (N) के साथ परीक्षण किया है इसलिए यह संभव है कि NVARCHAR (N) के लिए एक अलग सूत्र हो। यहाँ VARCHAR (N) का सूत्र है:

(पंक्ति अनुमान) = (तालिका में पंक्तियाँ) * (-0.004869 + ०.०३२६४ ९ * लॉग १० (डेटा प्रकार की लंबाई)

यह एक बहुत अच्छा फिट है, लेकिन यह पूरी तरह से सही नहीं है:

पहला सूत्र ग्राफ

X- अक्ष डेटा प्रकार की लंबाई है और y अक्ष 1 मिलियन पंक्तियों वाली तालिका के लिए अनुमानित पंक्तियों की संख्या है।

यदि आप स्तंभ पर आंकड़े नहीं रखते या क्वेरी स्तंभ में पर्याप्त NULL मान 1 से नीचे की औसत लंबाई को चलाने के लिए पर्याप्त सूत्र हैं, तो क्वेरी ऑप्टिमाइज़र इस सूत्र का उपयोग करेगा।

उदाहरण के लिए, मान लें कि आपके पास VARCHAR (50) पर फ़िल्टर करने के साथ 150k पंक्तियों वाली कोई तालिका नहीं थी और कोई स्तंभ आँकड़े नहीं थे। पंक्ति अनुमान भविष्यवाणी है:

150000 * (-0.004869 + 0.032649 * log10 (50)) = 7590.1 पंक्तियाँ

एसक्यूएल यह परीक्षण करने के लिए:

CREATE TABLE X_CE_LIKE_TEST_1 (
STRING VARCHAR(50)
);

CREATE STATISTICS X_STAT_CE_LIKE_TEST_1 ON X_CE_LIKE_TEST_1 (STRING) WITH NORECOMPUTE;

WITH
    L0 AS (SELECT 1 AS c UNION ALL SELECT 1),
    L1 AS (SELECT 1 AS c FROM L0 A CROSS JOIN L0 B),
    L2 AS (SELECT 1 AS c FROM L1 A CROSS JOIN L1 B),
    L3 AS (SELECT 1 AS c FROM L2 A CROSS JOIN L2 B),
    L4 AS (SELECT 1 AS c FROM L3 A CROSS JOIN L3 B CROSS JOIN L2 C),
    NUMS AS (SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS NUM FROM L4)  
    INSERT INTO X_CE_LIKE_TEST_1 WITH (TABLOCK) (STRING)
    SELECT TOP (150000) 'ZZZZZ'
    FROM NUMS
    ORDER BY NUM;

DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM X_CE_LIKE_TEST_1
WHERE STRING LIKE @LastName;

एसक्यूएल सर्वर 7242.47 की एक अनुमान पंक्ति गिनती देता है जो कि करीब है।

यदि FLOOR (औसत कुंजी लंबाई)> = 1 तो एक अलग सूत्र का उपयोग किया जाता है जो कि FLOOR (औसत लंबाई लंबाई) के मूल्य पर आधारित होता है। यहाँ कुछ मानों की एक तालिका दी गई है, जिन्हें मैंने आज़माया है:

1    1.5%
2    1.5%
3    1.64792%
4    2.07944%
5    2.41416%
6    2.68744%
7    2.91887%
8    3.11916%
9    3.29584%
10   3.45388%

यदि FLOOR (औसत कुंजी लंबाई) <6 तो ऊपर दी गई तालिका का उपयोग करें। अन्यथा निम्नलिखित समीकरण का उपयोग करें:

(पंक्ति अनुमान) = (तालिका में पंक्तियाँ) * (-0.003381 + 0.034539 * log10 (FLOOR (औसत कुंजी लंबाई)))

यह एक दूसरे की तुलना में बेहतर है, लेकिन यह अभी भी पूरी तरह से सही नहीं है।

दूसरा सूत्र ग्राफ

X- अक्ष औसत कुंजी लंबाई है और y अक्ष 1 मिलियन पंक्तियों वाली तालिका के लिए अनुमानित पंक्तियों की संख्या है।

एक और उदाहरण देने के लिए, मान लीजिए कि आपके पास फ़िल्टर्ड कॉलम पर आँकड़ों के लिए 5.5 की औसत लंबाई के साथ 10k पंक्तियों वाली एक तालिका थी। पंक्ति का अनुमान होगा:

10000 * 0.241416 = 241.416 पंक्तियाँ।

एसक्यूएल यह परीक्षण करने के लिए:

CREATE TABLE X_CE_LIKE_TEST_2 (
STRING VARCHAR(50)
);

WITH
    L0 AS (SELECT 1 AS c UNION ALL SELECT 1),
    L1 AS (SELECT 1 AS c FROM L0 A CROSS JOIN L0 B),
    L2 AS (SELECT 1 AS c FROM L1 A CROSS JOIN L1 B),
    L3 AS (SELECT 1 AS c FROM L2 A CROSS JOIN L2 B),
    L4 AS (SELECT 1 AS c FROM L3 A CROSS JOIN L3 B CROSS JOIN L2 C),
    NUMS AS (SELECT ROW_NUMBER() OVER (ORDER BY (SELECT NULL)) AS NUM FROM L4)  
    INSERT INTO X_CE_LIKE_TEST_2 WITH (TABLOCK) (STRING)
    SELECT TOP (10000) 
    CASE 
      WHEN NUM % 2 = 1 THEN REPLICATE('Z', 5) 
      ELSE REPLICATE('Z', 6)
    END
    FROM NUMS
    ORDER BY NUM;

CREATE STATISTICS X_STAT_CE_LIKE_TEST_2 ON X_CE_LIKE_TEST_2 (STRING) 
WITH NORECOMPUTE, FULLSCAN;

DECLARE @LastName VARCHAR(15) = 'BA%'
SELECT * FROM X_CE_LIKE_TEST_2
WHERE STRING LIKE @LastName;

पंक्ति का अनुमान 241.416 है जो आपके प्रश्न में मेल खाता है। यदि टेबल में कोई मान नहीं है तो कुछ त्रुटि होगी।

यहाँ मॉडल सही नहीं हैं, लेकिन मुझे लगता है कि वे सामान्य व्यवहार को बहुत अच्छी तरह से चित्रित करते हैं।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.