Förstå frågeplaner

  • 11 minuter

Det är viktigt att förstå hur databasoptimerare fungerar innan du går in på körningsplaninformation. SQL Server använder en kostnadsbaserad frågeoptimerare som beräknar kostnaden för flera möjliga planer baserat på statistik som den har på de kolumner som används och potentiella index för varje åtgärd i frågeplanen. Den här informationen hjälper optimeraren att fastställa den totala kostnaden för varje plan. Komplexa frågor kan ha tusentals möjliga körningsplaner, men optimeraren utvärderar inte var och en. I stället använder den heuristik för att identifiera planer som sannolikt kommer att fungera bra och väljer sedan den lägsta kostnadsplanen från de utvärderade.

Eftersom frågeoptimeraren är kostnadsbaserad är det viktigt att ge den korrekta indata för beslutsfattandet. SQL Server förlitar sig på statistik för att spåra fördelningen av data i kolumner och index, och den här statistiken måste hållas uppdaterad för att undvika att generera icke-optimala körningsplaner. Även om SQL Server automatiskt uppdaterar sin statistik när data ändras i en tabell, kan det krävas mer frekventa uppdateringar för att snabbt ändra data. Optimeraren tar hänsyn till många faktorer när du skapar en plan, inklusive databasens kompatibilitetsnivå, raduppskattningar baserat på statistik och tillgängliga index.

När en användare skickar en fråga till databasmotorn sker följande process:

  1. Frågan parsas för korrekt syntax, och om det är rätt genereras ett parsningsträd med databasobjekt.
  2. Parsningsträdet matas sedan in till en databasmotorkomponent som kallas Algebrizer för bindning. Det här steget verifierar att kolumner och objekt i frågan finns och identifierar de datatyper som bearbetas. Utdata är ett frågeprocessorträd som fungerar som indata för nästa steg.
  3. Frågeoptimeringen är processorintensiv, så databasmotorn cachelagrar körningsplaner i ett särskilt minnesområde som kallas plancachen. Om det redan finns en plan för frågan hämtas den från cacheminnet. Varje fråga i cacheminnet har ett hash-värde som genereras baserat på T-SQL i frågan, vilket kallas query_hash. Motorn genererar en query_hash för den aktuella frågan och söker efter matchningar i plancachen.
  4. Om det inte finns någon plan använder Frågeoptimeraren sin kostnadsbaserade optimerare för att generera flera körningsplanalternativ baserat på statistik om de kolumner, tabeller och index som används i frågan. Utdata är en frågekörningsplan.
  5. Frågan körs med hjälp av en körningsplan från plancachen eller en ny plan som genererades i föregående steg. Utdata är resultatet av din fråga.

Kommentar

Mer information om hur frågeprocessorn fungerar finns i Arkitekturguide för frågebearbetning

Låt oss titta på ett exempel. Överväg följande fråga:

SELECT orderdate,
        AVG(salesAmount)
FROM FactResellerSales
WHERE ShipDate = '2013-07-07'
GROUP BY orderdate;

I det här exemplet kontrollerar SQL Server om kolumnerna OrderDate, ShipDate och SalesAmount finns i tabellen FactResellerSales . Om dessa kolumner finns genererar SQL Server ett hash-värde för frågan och undersöker planens cache för ett matchande hash-värde. Om ett matchande hash-värde hittas försöker motorn återanvända planen. Om inget matchande hash-värde hittas undersöker SQL Server den tillgängliga statistiken för kolumnerna OrderDate och ShipDate .

WHERE Satsen som refererar till kolumnen ShipDate kallas predikatet i den här frågan. Om det finns ett icke-grupperat index som innehåller kolumnen ShipDate kommer SQL Server sannolikt att inkludera det i planen, förutsatt att kostnaderna är lägre än att hämta data från det klustrade indexet. Optimeraren väljer sedan den lägsta kostnadsplanen från de tillgängliga alternativen och kör frågan.

Frågeplaner kombinerar en serie relationsoperatorer för att hämta data och samla in information, till exempel uppskattat antal rader. Ett annat element i körningsplanen är det minne som krävs för åtgärder som att koppla eller sortera data, vilket kallas minnesbidrag. Minnesbidraget belyser statistikens betydelse. Om SQL Server uppskattar att en operator returnerar 10 000 000 rader när den faktiskt returnerar 100 allokeras ett större minnesbidrag till frågan. Ett alltför stort minnesbidrag kan orsaka två problem. Först kan frågan få vänta RESOURCE_SEMAPHORE , vilket indikerar att den väntar på att SQL Server ska allokera en stor mängd minne. SQL Server väntar som standard på 25 gånger kostnaden för frågan (i sekunder) innan den körs, upp till 24 timmar. För det andra, om det inte finns tillräckligt med minne tillgängligt när frågan körs, spills den till tempdb, vilket är långsammare än att arbeta i minnet.

Körningsplanen lagrar även andra metadata om frågan, till exempel databasens kompatibilitetsnivå, graden av parallellitet och de parametrar som anges om frågan parametriseras.

Frågeplaner kan visas antingen i en grafisk representation eller i ett textbaserat format. Textbaserade alternativ anropas med SET-kommandon och gäller endast för den aktuella anslutningen. Dessa planer kan visas var du än kan köra T-SQL-frågor.

De flesta DBA:er föredrar grafiska planer eftersom de gör att du kan se planen som helhet, inklusive planens form . Det finns flera sätt att visa och spara grafiska frågeplaner. Det vanligaste verktyget för detta ändamål är SQL Server Management Studio. Dessutom finns det verktyg från tredje part som stöder visning av grafiska körningsplaner.

Det finns tre olika typer av körningsplaner.

Uppskattad körningsplan

Den här typen av körningsplan genereras av frågeoptimeraren. Metadata och storleken på frågans minnesbeviljande baseras på uppskattningar från statistiken som finns i databasen vid tidpunkten för frågekompilering. Om du vill se en textbaserad uppskattad plan kör du kommandot SET SHOWPLAN_ALL ON innan du kör frågan. När du kör frågan visas stegen i körningsplanen, men frågan körs inte och du ser inga resultat. SET-alternativet gäller tills du ställer in av.

Faktisk körningsplan

Den här typen av plan är samma som den uppskattade planen. Men den innehåller även körningskontexten för frågan. Den här kontexten innehåller det uppskattade och faktiska radantalet, eventuella körningsvarningar, den faktiska graden av parallellitet (antal processorer som används) och de förflutna och CPU-tiderna som användes under körningen. Om du vill se en textbaserad faktisk plan kör du kommandot SET STATISTICS PROFILE ON innan du kör frågan. Frågan körs och du får både planen och resultatet.

Statistik för livefrågor

Det här visningsalternativet för planen kombinerar de uppskattade och faktiska planerna till en animerad plan som visar körningsframstatus via operatorerna. Den uppdateras varje sekund och visar det faktiska antalet rader som flödar genom operatorerna. En annan fördel med livefrågestatistik är att den visar överlämningen från operatör till operatör, vilket kan vara användbart vid felsökning av prestandaproblem. Eftersom den här typen av plan är animerad är den endast tillgänglig som en grafisk plan.