Nummerseriegenerator-udfordringsløsninger – del 3

Her er de tidsstatistikker, jeg fik for denne udførelse:

Som forventet er dette ikke så hurtigt som med et interval, der starter med 1, men interessant nok hurtigere end med et interval, der starter med 0.

Fjerner 0-vagtpostrækken

I betragtning af at teknikken med vagtpostrækken med værdien 0 ser ud til at være langsommere end at anvende manipulation på rownum, giver det mening simpelthen at undgå det. Dette bringer os til en forenklet horisontal eliminationsbaseret løsning, der blander ideerne fra Alan, Charlie, Joe og mig selv. Jeg kalder funktionen med denne løsning dbo.GetNumsAlanCharlieJoeItzikBatch. Her er 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

Lad os teste det med området 1 til 100M:

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

Planen er den samme som den, der er vist tidligere i figur 3, som forventet.

Derfor fik jeg følgende tidsstatistik:

Test det med intervallet 0 til 99.999.999:

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

Denne gang får du den samme plan som den, der er vist tidligere i figur 5 – ikke figur 4.

Her er de tidsstatistikker, jeg fik for denne udførelse:

Test det med området 2 til 100.000.001:

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

Igen får du den samme plan som den, der er vist tidligere i figur 5.

Jeg fik følgende tidsstatistik for denne udførelse:

Forbehold ved brug af ikke-konstante input

Med teknikker til eliminering af både vertikale og horisontale enheder fungerer tingene ideelt, så længe du sender konstanter som input. Du skal dog være opmærksom på advarsler, der kan resultere i præstationsstraffe, når du passerer ikke-konstante input. Teknikken til eliminering af vertikale enheder har færre problemer, og de problemer, der findes, er nemmere at håndtere, så lad os starte med det.

Husk, at vi i denne artikel brugte funktionen dbo.GetNumsAlanCharlieItzikBatch som vores eksempel, der er afhængig af konceptet for lodret enhed eliminering. Lad os køre en række tests med ikke-konstante input, såsom variabler.

Som vores første test returnerer vi rn og beder om dataene bestilt af 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);

Husk, at rn repræsenterer det umanipulerede ROW_NUMBER-udtryk, så det faktum, at vi bruger ikke-konstante input, har ingen særlig betydning i dette tilfælde. Der er ikke behov for eksplicit sortering i planen.

Jeg fik følgende tidsstatistik for denne udførelse:

Disse tal repræsenterer det ideelle tilfælde.

I den næste test skal du bestille resultatrækkerne 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 for denne udførelse er vist i figur 6.

Figur 6:Plan for dbo.GetNumsAlanCharlieItzikBatch(@)mylow, @ orderingmy n

Kan du se problemet? Efter inlining blev @low erstattet med @mylow—ikke med værdien i @mylow, som er 1. Konstant foldning fandt derfor ikke sted, og derfor er n ikke ordensbevarende i forhold til rownum. Dette resulterede i eksplicit sortering i planen.

Her er de tidsstatistikker, jeg fik for denne udførelse:

Udførelsestiden er næsten tredoblet i forhold til, hvor eksplicit sortering ikke var nødvendig.

En simpel løsning er at bruge Alan Bursteins oprindelige idé til altid at bestille efter rn, når du skal have resultatet bestilt, både når du returnerer rn og når du returnerer n, som sådan:

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

Denne gang er der ingen eksplicit sortering i planen.

Jeg fik følgende tidsstatistik for denne udførelse:

Tallene afspejler tilstrækkeligt det faktum, at du returnerer det manipulerede udtryk, men ikke pådrager sig nogen eksplicit sortering.

Med løsninger, der er baseret på den horisontale enheds-elimineringsteknik, såsom vores dbo.GetNumsAlanCharlieJoeItzikBatch-funktion, er situationen mere kompliceret, når der bruges ikke-konstante input.

Lad os først teste funktionen med et meget lille interval på 10 tal:

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 for denne udførelse er vist i figur 7.

Figur 7:Plan for dbo.GetNumsAlanCharlieJoeItzikBatch(@mylow), @myhigh)

Der er en meget alarmerende side ved denne plan. Bemærk, at filteroperatorerne vises nedenunder de bedste operatører! I ethvert givet kald til funktionen med ikke-konstante input vil en af ​​grenene under Sammenkædningsoperatoren naturligvis altid have en falsk filtertilstand. Begge topoperatører beder dog om et antal rækker, der ikke er nul. Så topoperatoren over operatoren med den falske filterbetingelse vil bede om rækker og vil aldrig være tilfreds, da filteroperatoren vil blive ved med at kassere alle rækker, som den får fra sin underordnede node. Arbejdet i undertræet under filteroperatoren skal køre til fuldførelse. I vores tilfælde betyder det, at undertræet vil gennemgå arbejdet med at generere 4B rækker, som Filter-operatoren vil kassere. Du undrer dig over, hvorfor filteroperatøren gider at anmode om rækker fra sin underordnede node, men det ser ud til, at det er sådan, det fungerer i øjeblikket. Det er svært at se dette med en statisk plan. Det er nemmere at se dette live, for eksempel med muligheden for udførelse af live-forespørgsler i SentryOne Plan Explorer, som vist i figur 8. Prøv det.

Figur 8:Direkte forespørgselsstatistik for dbo.GetNumsAlanCharlie @JoeItzikBat,chmy@highmylow,chmy

Det tog denne test 9:15 minutter at gennemføre på min maskine, og husk, at anmodningen var at returnere et interval på 10 numre.

Lad os tænke på, om der er en måde at undgå at aktivere det irrelevante undertræ i sin helhed. For at opnå dette, vil du gerne have, at opstartsfilteroperatørerne vises ovenfor topoperatørerne i stedet for under dem. Hvis du læser Fundamentals of table expressions, Del 4 – Afledte tabeller, optimeringsovervejelser, fortsat, ved du, at et TOP-filter forhindrer unnesting af tabeludtryk. Så alt hvad du skal gøre er at placere TOP-forespørgslen i en afledt tabel og anvende filteret i en ydre forespørgsel mod den afledte tabel.

Her er vores modificerede funktion, der implementerer dette 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 forventet bliver henrettelser med konstanter ved med at opføre sig og udføre det samme som uden tricket.

Hvad angår ikke-konstante input, er det nu med små områder meget hurtigt. Her er en test med et interval på 10 numre:

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 for denne udførelse er vist i figur 9.

Figur 9:Plan for forbedret 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);