Bent u gesorteerd? Tips met betrekking tot het bestellen van T-SQL-vensters

De volgende code implementeert een weergave op basis van deze aanbeveling:

CREATE OR ALTER VIEW dbo.MyView
AS
 
SELECT orderid, orderdate, custid,
 
  MAX(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING) AS max1,
 
  SUM(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING) AS sum1,
 
  AVG(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING) AS avg1,
 
  MAX(orderid) OVER(ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS max3,
 
  SUM(1.0 * orderid) OVER(ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS sum3,
 
  AVG(1.0 * orderid) OVER(ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS avg3,
 
  MAX(orderid) OVER(PARTITION BY custid ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS max2,
 
  AVG(orderid) OVER(PARTITION BY custid ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS avg2,
 
  SUM(orderid) OVER(PARTITION BY custid ORDER BY ordered ROWS UNBOUNDED PRECEDING) AS sum2
 
FROM dbo.Orders;
GO

Vraag nu de weergave op en vraag alleen om de resultaatkolommen sum2, sum1 en sum3, in deze volgorde:

SELECT orderid, orderdate, custid,
  sum2, sum1, sum3
FROM dbo.MyView
ORDER BY custid, orderid;

Ik zal naar deze query verwijzen als Query 8. U krijgt het plan weergegeven in Afbeelding 8 met slechts twee soorten.

Figuur 8:Plan voor Query 8

Tip 6

Wanneer u een vraag heeft met meerdere vensterfuncties met meerdere duidelijke bestelbehoeften, is de algemene wijsheid dat u slechts één daarvan kunt ondersteunen met vooraf bestelde gegevens via een index. Dit is zelfs het geval wanneer alle vensterfuncties respectievelijke ondersteunende indexen hebben.

Laat me dit aantonen. Herinner u eerder toen u de index idx_nc_cid_od_oid maakte, die vensterfuncties kan ondersteunen die de gegevens nodig hebben die zijn geordend op custid, orderdate, orderid, zoals de volgende uitdrukking:

SUM(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING)

Stel dat je naast deze vensterfunctie ook de volgende vensterfunctie nodig hebt in dezelfde query:

SUM(orderid) OVER(PARTITION BY custid ORDER BY orderid ROWS UNBOUNDED PRECEDING)

Deze vensterfunctie zou baat hebben bij de volgende index:

CREATE UNIQUE NONCLUSTERED INDEX idx_nc_cid_oid ON dbo.Orders(custid, orderid);

De volgende vraag, die ik vraag 9 zal noemen, roept beide vensterfuncties op:

SELECT orderid, orderdate, custid,
 
  SUM(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING) AS sum1,
 
  SUM(orderid) OVER(PARTITION BY custid ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS sum2
 
FROM dbo.Orders;

Het plan voor deze zoekopdracht wordt getoond in figuur 9.

Figuur 9:Plan voor Query 9

Ik krijg de volgende tijdstatistieken voor deze zoekopdracht op mijn computer, met resultaten weggegooid in SSMS:

CPU time = 3234 ms,  elapsed time = 3354 ms.

Zoals eerder uitgelegd, scant SQL Server de vensterexpressies in volgorde van voorkomen in de query en denkt dat het de eerste kan ondersteunen met een geordende scan van de index idx_nc_cid_od_oid. Maar dan voegt het een sorteeroperator toe aan het plan om de gegevens te ordenen zoals de tweede vensterfunctie nodig heeft. Dit betekent dat het plan N log N schaling heeft. Het overweegt niet om de index idx_nc_cid_oid te gebruiken om de tweede vensterfunctie te ondersteunen. Je denkt waarschijnlijk dat het niet kan, maar probeer een beetje buiten de kaders te denken. Zou je niet elk van de vensterfuncties kunnen berekenen op basis van de respectieve indexvolgorde en dan de resultaten samenvoegen? Theoretisch kan dat, en afhankelijk van de grootte van de gegevens, de beschikbaarheid van indexering en andere beschikbare bronnen, zou de join-versie het soms beter kunnen doen. SQL Server houdt geen rekening met deze benadering, maar je kunt het zeker implementeren door de join zelf te schrijven, zoals:

WITH C1 AS
(
  SELECT orderid, orderdate, custid,
 
    SUM(orderid) OVER(PARTITION BY custid ORDER BY orderdate, orderid ROWS UNBOUNDED PRECEDING) AS sum1
 
  FROM dbo.Orders
),
C2 AS
(
  SELECT orderid, custid,
 
    SUM(orderid) OVER(PARTITION BY custid ORDER BY orderid ROWS UNBOUNDED PRECEDING) AS sum2
 
  FROM dbo.Orders
)
SELECT C1.orderid, C1.orderdate, C1.custid, C1.sum1, C2.sum2
FROM C1
  INNER JOIN C2
    ON C1.orderid = C2.orderid;

Ik noem deze query Query 10. Het plan voor deze query wordt getoond in Afbeelding 10.

Figuur 10:Plan voor Query 10

Het plan gebruikt geordende scans van de twee indexen zonder enige expliciete sortering, berekent de vensterfuncties en gebruikt een hash-join om de resultaten samen te voegen. Dit plan wordt lineair geschaald in vergelijking met het vorige, dat een N log N-schaal heeft.

Ik krijg de volgende tijdstatistieken voor deze zoekopdracht op mijn computer (opnieuw met de resultaten weggegooid in SSMS):

CPU time = 1000 ms,  elapsed time = 1100 ms.

Om het samen te vatten, hier is onze zesde tip.

Tip 6:Als je meerdere vensterfuncties hebt met meerdere verschillende bestelbehoeften, en je kunt ze allemaal ondersteunen met indexen, probeer dan een join-versie en vergelijk de prestaties met de query zonder de join.

Opruimen

Als u parallellisme hebt uitgeschakeld door de configuratieoptie MAXDOP met databasebereik in te stellen op 1, schakelt u parallellisme opnieuw in door het in te stellen op 0:

ALTER DATABASE SCOPED CONFIGURATION SET MAXDOP = 0;

Als je de ongedocumenteerde sessie-optie DBCC OPTIMIZER_WHATIF hebt gebruikt met de CPU-optie ingesteld op 1, schakel dan parallellisme opnieuw in door deze op 0 in te stellen:

DBCC OPTIMIZER_WHATIF(CPUs, 0);

Je kunt alle voorbeelden opnieuw proberen met parallellisme ingeschakeld als je wilt.

Gebruik de volgende code om de nieuwe indexen die u hebt gemaakt op te schonen:

DROP INDEX IF EXISTS idx_nc_cid_od_oid ON dbo.Orders;
DROP INDEX IF EXISTS idx_nc_cid_oid ON dbo.Orders;

En de volgende code om de weergave te verwijderen:

DROP VIEW IF EXISTS dbo.MyView;

Volg de tips om het aantal sorteringen te minimaliseren

Vensterfuncties moeten de bestelde invoergegevens verwerken. Indexering kan helpen bij het elimineren van sorteren in het plan, maar normaal gesproken alleen voor één duidelijke bestelbehoefte. Query's met meerdere bestelbehoeften hebben meestal een aantal soorten in hun plannen. Door bepaalde tips op te volgen, kunt u het aantal benodigde soorten echter minimaliseren. Hier is een samenvatting van de tips die ik in dit artikel heb genoemd:

• Tip 1: Als u een index hebt om sommige vensterfuncties in de query te ondersteunen, geeft u deze eerst op.
• Tip 2: Als de query vensterfuncties omvat met dezelfde bestelbehoefte als de presentatievolgorde in de query, geeft u die functies als laatste op.
• Tip 3: Zorg ervoor dat u tips 1 en 2 volgt voor het eerste optreden van elke afzonderlijke bestelbehoefte. Opeenvolgende gevallen van dezelfde ordeningsbehoefte, zelfs als ze niet aangrenzend zijn, worden geïdentificeerd en samen met de eerste gegroepeerd.
• Tip 4: De bovengenoemde aanbevelingen zijn van toepassing op de weergavevolgorde van vensterfuncties in de code, zelfs binnen een benoemde tabelexpressie zoals een CTE of view, en zelfs als de buitenste query de kolommen in een andere volgorde retourneert dan in de benoemde tabelexpressie. Daarom, als u kolommen in een bepaalde volgorde in de uitvoer moet retourneren en deze verschilt van de optimale volgorde in termen van het minimaliseren van sorteringen in het plan, volgt u de tips in termen van weergavevolgorde binnen een benoemde tabelexpressie en retourneert u de kolommen in de buitenste query in de gewenste uitvoervolgorde.
• Tip 5: In de innerlijke query van een benoemde tabeluitdrukking zoals een CTE of view, groepeert u alle vensterfuncties met dezelfde bestelbehoeften bij elkaar en volgt u tips 1 en 2 in de volgorde van de groepen functies.
• Tip 6: Als je meerdere vensterfuncties hebt met meerdere verschillende bestelbehoeften, en je kunt ze allemaal ondersteunen met indexen, probeer dan een join-versie en vergelijk de prestaties met de query zonder de join.