Utmaningslösningar för nummerseriegenerator – del 3

Den här gången finns det ingen dyr sammanslagningslogik eftersom vaktpostdelen är irrelevant. Observera dock att den returnerade kolumnen är det manipulerade uttrycket @low – 1 + rownum, som efter parameterinbäddning/inlining och konstant vikning blev 1 + rownum.

Här är tidsstatistiken som jag fick för den här exekveringen:

Som förväntat är detta inte lika snabbt som med ett intervall som börjar med 1, men intressant nog snabbare än med ett intervall som börjar med 0.

Ta bort 0-vaktraden

Med tanke på att tekniken med sentinel-raden med värdet 0 verkar vara långsammare än att tillämpa manipulation på rownum, är det vettigt att helt enkelt undvika det. Detta för oss till en förenklad horisontell elimineringsbaserad lösning som blandar idéerna från Alan, Charlie, Joe och mig själv. Jag kallar funktionen med denna lösning dbo.GetNumsAlanCharlieJoeItzikBatch. Här är funktionens definition:

CREATE OR ALTER FUNCTION dbo.GetNumsAlanCharlieJoeItzikBatch(@low AS BIGINT = 1, @high AS BIGINT)
  RETURNS TABLE
AS
RETURN
  WITH
    L0 AS ( SELECT 1 AS c
            FROM (VALUES(1),(1),(1),(1),(1),(1),(1),(1),
                        (1),(1),(1),(1),(1),(1),(1),(1)) AS D(c) ),
    L1 AS ( SELECT 1 AS c FROM L0 AS A CROSS JOIN L0 AS B ),
    L2 AS ( SELECT 1 AS c FROM L1 AS A CROSS JOIN L1 AS B ),
    L3 AS ( SELECT 1 AS c FROM L2 AS A CROSS JOIN L2 AS B ),
    Nums AS ( SELECT ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS rownum
              FROM L3 )
  SELECT TOP(@high)
     rownum AS n,
     @high + 1 - rownum AS op
  FROM Nums LEFT OUTER JOIN dbo.BatchMe ON 1 = 0
  WHERE @low = 1
  ORDER BY rownum
  UNION ALL
  SELECT TOP(@high - @low + 1)
     @low - 1 + rownum AS n,
     @high + 1 - rownum AS op
  FROM Nums LEFT OUTER JOIN dbo.BatchMe ON 1 = 0
  WHERE @low <> 1
  ORDER BY rownum;
GO

Låt oss testa det med intervallet 1 till 100M:

DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(1, 100000000) ORDER BY n OPTION(MAXDOP 1);

Planen är densamma som den som visas tidigare i figur 3, som förväntat.

Följaktligen fick jag följande tidsstatistik:

Testa det med intervallet 0 till 99 999 999:

DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(0, 99999999) ORDER BY n OPTION(MAXDOP 1);

Den här gången får du samma plan som den som visades tidigare i figur 5—inte figur 4.

Här är tidsstatistiken som jag fick för den här körningen:

Testa det med intervallet 2 till 100 000 001:

DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(2, 100000001) ORDER BY n OPTION(MAXDOP 1);

Återigen får du samma plan som den som visades tidigare i figur 5.

Jag fick följande tidsstatistik för denna körning:

Varningar vid användning av icke-konstanta indata

Med teknikerna för eliminering av både vertikala och horisontella enheter fungerar saker idealiskt så länge du skickar konstanter som indata. Du måste dock vara medveten om varningar som kan resultera i prestationsstraff när du passerar icke-konstanta ingångar. Tekniken för att eliminera vertikala enheter har färre problem, och de problem som finns är lättare att hantera, så låt oss börja med det.

Kom ihåg att vi i den här artikeln använde funktionen dbo.GetNumsAlanCharlieItzikBatch som vårt exempel som bygger på konceptet för att eliminera vertikala enheter. Låt oss köra en serie tester med icke-konstanta indata, till exempel variabler.

Som vårt första test kommer vi att returnera rn och fråga efter data som beställts av rn:

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 100000000;
 
DECLARE @n AS BIGINT;
 
SELECT @n = rn FROM dbo.GetNumsAlanCharlieItzikBatch(@mylow, @myhigh) ORDER BY rn OPTION(MAXDOP 1);

Kom ihåg att rn representerar det omanipulerade uttrycket ROW_NUMBER, så det faktum att vi använder icke-konstanta indata har ingen speciell betydelse i det här fallet. Det finns inget behov av explicit sortering i planen.

Jag fick följande tidsstatistik för denna körning:

Dessa siffror representerar det ideala fallet.

I nästa test, ordna resultatraderna efter n:

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 100000000;
 
DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieItzikBatch(@mylow, @myhigh) ORDER BY n OPTION(MAXDOP 1);

Planen för detta utförande visas i figur 6.

Figur 6:Planera för dbo.GetNumsAlanCharlieItzikBatch(@)mylow, @beställning n

Ser du problemet? Efter inlining ersattes @low med @mylow—inte med värdet i @mylow, vilket är 1. Följaktligen skedde inte konstant vikning, och därför är n inte ordningsbevarande med avseende på rownum. Detta resulterade i en explicit sortering i planen.

Här är tidsstatistiken som jag fick för den här exekveringen:

Exekveringstiden nästan tredubblades jämfört med när explicit sortering inte behövdes.

En enkel lösning är att använda Alan Bursteins ursprungliga idé att alltid beställa efter rn när du behöver resultatet beställt, både när du returnerar rn och när du returnerar n, som så:

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 100000000;
 
DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieItzikBatch(@mylow, @myhigh) ORDER BY rn OPTION(MAXDOP 1);

Den här gången finns det ingen explicit sortering i planen.

Jag fick följande tidsstatistik för denna körning:

Siffrorna återspeglar på ett adekvat sätt det faktum att du returnerar det manipulerade uttrycket, men inte medför någon explicit sortering.

Med lösningar som är baserade på tekniken för eliminering av horisontella enheter, såsom vår dbo.GetNumsAlanCharlieJoeItzikBatch-funktion, är situationen mer komplicerad när man använder icke-konstanta indata.

Låt oss först testa funktionen med ett mycket litet intervall på 10 siffror:

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 10;
 
DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(@mylow, @myhigh) ORDER BY n OPTION(MAXDOP 1);

Planen för detta utförande visas i figur 7.

Figur 7:Plan för dbo.GetNumsAlanCharlieJoeItzikBatch(@mylow), @myhigh)

Det finns en mycket alarmerande sida av denna plan. Observera att filteroperatorerna visas nedan de bästa operatörerna! I varje givet anrop till funktionen med icke-konstanta ingångar kommer naturligtvis alltid en av grenarna under operatören Konkatenering alltid att ha ett falskt filtertillstånd. Båda toppoperatörerna ber dock om ett antal rader som inte är noll. Så topoperatorn ovanför operatorn med det falska filtervillkoret kommer att fråga efter rader och kommer aldrig att bli nöjd eftersom filteroperatorn kommer att fortsätta att kassera alla rader som den kommer att få från sin undernod. Arbetet i underträdet under filteroperatorn måste köras till slut. I vårt fall betyder detta att underträdet kommer att gå igenom arbetet med att generera 4B rader, som filteroperatorn kommer att förkasta. Du undrar varför filteroperatorn stör sig på att begära rader från sin undernod, men det verkar som om det är så det fungerar för närvarande. Det är svårt att se detta med en statisk plan. Det är lättare att se detta live, till exempel med alternativet för körning av frågor i SentryOne Plan Explorer, som visas i figur 8. Prova det.

Figur 8:Live frågestatistik för dbo.GetNumsAlanCharlieJoeIghmylow,chmy @hi@highmylowBat,chmy

Det tog det här testet 9:15 minuter att slutföra på min maskin, och kom ihåg att begäran var att returnera ett intervall på 10 nummer.

Låt oss fundera på om det finns ett sätt att undvika att aktivera det irrelevanta underträdet i sin helhet. För att uppnå detta skulle du vilja att startfilteroperatorerna visas ovanför toppoperatörerna istället för under dem. Om du läser Fundamentals of table expressions, Del 4 – Härledda tabeller, optimeringsöverväganden, fortsättning, vet du att ett TOP-filter förhindrar att tabelluttryck tas bort. Så allt du behöver göra är att placera TOP-frågan i en härledd tabell och tillämpa filtret i en yttre fråga mot den härledda tabellen.

Här är vår modifierade funktion som implementerar detta trick:

CREATE OR ALTER FUNCTION dbo.GetNumsAlanCharlieJoeItzikBatch(@low AS BIGINT = 1, @high AS BIGINT)
  RETURNS TABLE
AS
RETURN
  WITH
    L0 AS ( SELECT 1 AS c
            FROM (VALUES(1),(1),(1),(1),(1),(1),(1),(1),
                        (1),(1),(1),(1),(1),(1),(1),(1)) AS D(c) ),
    L1 AS ( SELECT 1 AS c FROM L0 AS A CROSS JOIN L0 AS B ),
    L2 AS ( SELECT 1 AS c FROM L1 AS A CROSS JOIN L1 AS B ),
    L3 AS ( SELECT 1 AS c FROM L2 AS A CROSS JOIN L2 AS B ),
    Nums AS ( SELECT ROW_NUMBER() OVER(ORDER BY (SELECT NULL)) AS rownum
              FROM L3 )
  SELECT *
  FROM ( SELECT TOP(@high)
            rownum AS n,
            @high + 1 - rownum AS op
         FROM Nums LEFT OUTER JOIN dbo.BatchMe ON 1 = 0
         ORDER BY rownum ) AS D1
  WHERE @low = 1
  UNION ALL
  SELECT *
  FROM ( SELECT TOP(@high - @low + 1)
            @low - 1 + rownum AS n,
            @high + 1 - rownum AS op
         FROM Nums LEFT OUTER JOIN dbo.BatchMe ON 1 = 0
         ORDER BY rownum ) AS D2
  WHERE @low <> 1;
GO

Som väntat fortsätter körningar med konstanter att bete sig och prestera på samma sätt som utan tricket.

När det gäller icke-konstanta ingångar, nu med små intervall är det väldigt snabbt. Här är ett test med ett intervall på 10 siffror:

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 10;
 
DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(@mylow, @myhigh) ORDER BY n OPTION(MAXDOP 1);

Planen för detta utförande visas i figur 9.

Figur 9:Planera för förbättrad dbo.GetNumsAlanCharlieJoeItzikBatch @my@high)

DECLARE @mylow AS BIGINT = 1, @myhigh AS BIGINT = 100000000;
 
DECLARE @n AS BIGINT;
 
SELECT @n = n FROM dbo.GetNumsAlanCharlieJoeItzikBatch(@mylow, @myhigh) ORDER BY n OPTION(MAXDOP 1);