SQL-förfrågeexekveringsplaner genereras när en frågeoptimerare bestämmer det mest effektiva sättet att leverera den data som efterfrågas av en fråga. Dessa planer är en representation av databasoperationerna som en fråga kör, och visar vilka objekt frågan använder, vilka typer av användningar och hur de används.
Det är allmänt känt att dåligt presterande frågor är en nyckelindikator på att något är fel i en databas. Så att titta "under huven" på en frågas exekveringsplan är ett av de bästa sätten att fastställa orsaken till prestandaproblemet.
Informationen som är tillgänglig i en SQL-exekveringsplan är ovärderlig för DBA:er som felsöker SQL Server-frågeprestandaproblem eftersom den gör det möjligt för dem att komma till grundorsaken till problemet och justera frågan efter behov.
Att granska SQL-exekveringsplaner är ett av de första stegen i prestandajustering eftersom planen tydligt belyser de mest troliga källorna till problem inom en fråga, inklusive dyra operatörer, ett ovanligt antal poster som flyter mellan operatörer och extra operatörer.
DBA:er drar också nytta av exekveringsplanvarningar som varnar användare om problem som tempdb-spill och saknade index.
Typer av SQL-exekveringsplaner
Det finns två huvudtyper av SQL-exekveringsplaner:beräknade exekveringsplaner och faktiska uppskattningsplaner.
Beräknade genomförandeplaner beskrivs bäst som en slags väderprognos. Som namnet antyder använder uppskattade exekveringsplaner ungefärliga beräkningar, statistik och andra parametrar för att uppskatta steg som kan följas av SQL Server Engine för att exekvera den skickade frågan efter att ha analyserat frågan.
Du behöver inte köra frågan för att generera den här typen av exekveringsplan, så den är bra för komplexa frågor där det skulle ta lång tid att generera en faktisk exekveringsplan.
Faktiska exekveringsplaner exekverar den skickade frågan och visar sedan stegen som inträffade under exekveringen. Denna typ av plan visar verkliga beräkningar och de faktiska (ej uppskattade) stegen som följs av SQL Server Engine.
Eftersom den här typen av exekveringsplan faktiskt kör frågan, är den ett bra val för att felsöka frågeprestandaproblem.
Hur man skapar en SQL-exekveringsplan
Hackernoon ger en kortfattad beskrivning av hur man genererar beräknade och faktiska genomförandeplaner. Processen kan kokas ner till följande steg:
Skapa en beräknad genomförandeplan
- Gå till databasen
- Markera frågan
- Klicka på "Fråga"
- Klicka på "Visa beräknad exekveringsplan" eller använd genvägen Ctrl + L
Skapa en verklig genomförandeplan
- Gå till databasen
- Markera frågan
- Klicka på "Fråga"
- Klicka på "Inkludera faktisk exekveringsplan" eller använd genvägen Ctrl + M
Du hittar en detaljerad förklaring av hur man genererar beräknade genomförandeplaner och faktiska genomförandeplaner i den officiella Microsoft-dokumentationen.
Varför uppskattade och faktiska SQL-exekveringsplaner kan vara olika
I allmänhet kommer uppskattade och faktiska genomförandeplaner att vara likartade. Men det finns tillfällen då de är olika. Detta är normalt och inträffar eftersom databasstatistiken och faktiska data är olika. Dessa skillnader kan introduceras genom flera kanaler:
Parallellism
Plankostnad kan göra att två exekveringsplaner skapas för en skickad fråga. SQL Server Engine kommer att välja om den parallella planen ska användas eller inte, så det är möjligt för en plan att använda den parallella planen och den andra att använda den seriella planen.
Inaktuell statistik
När du infogar data i och tar bort data från tabeller och index eller ändrar tabellen eller indexschemat kommer statistiken att ändras. Om statistiken inte uppdateras regelbundet kommer den faktiska genomförandeplanen att skilja sig från den beräknade genomförandeplanen.
Ogiltig beräknad plan
Om en fråga innehåller en sats som kräver en temporär tabell som bara existerar om frågan exekveras, kommer generering av en beräknad exekveringsplan att skapa ett fel eftersom ingen fråga har exekveras. Samma fråga skulle fungera bra i den faktiska körningsplanen eftersom frågan kördes.
SQL-exekveringsplaner är en värdefull resurs för att felsöka SQL Server-prestandaproblem. Att veta hur man genererar både uppskattade och faktiska SQL-exekveringsplaner är ett viktigt verktyg för alla DBA som har till uppgift att justera frågor för optimal prestanda.