Introduktion
SQL-forespørgsel beskriver det forventede resultat, ikke måden at få resultatet på. Sættet af specifikke trin, som serveren skal tage for at returnere resultatet, kaldes forespørgselsudførelsesplanen. Planen er bygget af optimizeren. Valg af en plan påvirker eksekveringshastigheden, hvilket gør den til et af de vigtigste elementer i forespørgselsydelsesproblemanalysen.
Udførelsesplan omfatter operatører og deres egenskaber, der er indbyrdes forbundne i form af træstrukturen. Hver operatør er ansvarlig for en separat logisk eller fysisk drift. Tilsammen sikrer de resultatet beskrevet i forespørgselsteksten. Inde i træet er operatører repræsenteret af klasseobjekterne i SQL Servers hukommelse. Serverbrugere (det vil sige dig og mig) ser beskrivelsen genereret i XML-format med et specifikt skema, der vises grafisk af SQL Server Management Studio-miljøet (SSMS).
Der er mange forskellige planoperatører og endnu flere ejendomme. Desuden dukker der nye op fra tid til anden. Denne artikel tør ikke beskrive alle mulige forskellige operatører. I stedet vil jeg gerne dele de mest interessante tilføjelser i dette emne og minde nogle gamle, men nyttige elementer.
Serverversion
Nogle gange kan du finde anmodninger om serverversionen på fora, selvom forespørgselsplanen er leveret i det korrekte format (XML). I stedet kan du spare tid og åbne eksekveringsplanen som XML. Og det første element, der beskriver planen, vil vise dig serverversionen i Build-egenskaben.
Denne metode tillader ikke at hente fuldstændig information om serverudgaven, men i de fleste tilfælde er det nok til at forstå, hvad vi beskæftiger os med.
Antal tabelrækker
Det andet hyppige spørgsmål er "Hvor mange rækker indeholder din tabel?". Disse oplysninger kan også hentes fra forespørgselsplanen (fra serverversion 2008). Til dette skal vi vælge dataadgangsoperatøren (Scan eller Seek) for den pågældende tabel og tage et kig på TableCardinality ejendom. Der er endnu en interessant egenskab, estimeret rækkestørrelse, til specifikation af rækkestørrelsen og omtrentlig evaluering af tabellen eller indeksstørrelsen (forudsat at tabellen ikke er komprimeret).
Jeg vil gerne bemærke, at dette ikke er et reelt antal rækker i en tabel, men data fra objektstatistikken. Disse data er dog grundlaget for de beslutninger, som optimizeren træffer, når den bygger en forespørgsel.
Kontekst
Forespørgselsplanen gemmer bemærkelsesværdige SET-indstillinger, som den er bygget til. For at se indstillingerne skal du vælge et rodelement i planen og udvide Indstil indstillinger ejendom. For eksempel kan vi finde ud af, om planen er bygget med ARITHABORT mulighed aktiveret (forskel mellem denne indstilling fører ofte til to forskellige planer og situationer med dårlig parametersniffing).
Antal CPU'er
Vi kan hente antallet af processorer, der er tilgængelige for optimizeren. Til dette skal vi åbne OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism parameter i det samme rodelement og gange det med 2. Hvis kun én processor er tilgængelig, er der ingen grund til at gange.
2*2 =4, 4 CPU'er er tilgængelige. Faktisk har jeg en processor med 4 kerner på min computer, og alle 4 kerner er tilgængelige for serveren. Disse oplysninger kan hjælpe dig med at finde den maskine, som planen blev genereret på.
Cardinality Estimator-version
Fra SQL Server 2014 er flere versioner af Cardinality Estimator (RU) blevet tilgængelige. Denne mekanisme påvirker de fleste beslutninger, som optimizer tager, når han vælger en plan. Du kan hente versionen af Cardinality Estimator fra CardinalityEstimationModelVersion egenskab for rodoperatøren.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Forespørgselsudførelsestid og ventetid
Fra og med SQL Server 2016 SP1 indeholder den faktiske forespørgselsplan information om eksekveringstid og processortid. For at hente disse data skal du udvide QueryTimeStats egenskab i rodelementet og se værdierne for CpuTime og Forløbet tid . Vi behøver ikke at aktivere indsamling af eksekveringstid eller spørge "hvor længe blev forespørgslen udført?" længere – alle disse oplysninger er inkluderet i planen.
Den anden bemærkelsesværdige forbedring er top 10 over de længste ventetider under udførelse af forespørgsler. Til dette skal vi udvide WaitStats egenskab i rodelementet. Denne tilføjelse gør det muligt at få mere præcise årsager til langsom udførelse af forespørgsler og forenkler diagnosticering betydeligt.
Parametertyper
Parameterlisten egenskab, der viser parametre brugt i forespørgslen, eksisterede i planen for længe siden. Men fra SQL Server 2016 SP1 er Parameter Data Type egenskaben er blevet tilføjet til parameterdefinitionen. Denne egenskab gemmer datatypen for parameteren. Det kan være nyttigt til at forstå problemer med typekonverteringen.
Antal rækker, der skal læses og estimeret antal rækker, der skal læses
Udførelsesplanen inkluderer to meget vigtige egenskaber, faktisk antal rækker og estimeret antal rækker. Disse egenskaber indeholder oplysninger om antallet af rækker, der returneres af datalæseoperatoren, men ikke antallet af rækker, den faktisk har læst. Egenskaberne Antallet af læste rækker og estimeret antal rækker, der skal læses, besvarer dette spørgsmål og gør det muligt at hente antallet af rækker, som serveren faktisk har læst eller vil læse. Egenskaben ActualRowsRead (Antal rækker læst i SSMS) er tilgængelig fra SQL Server 2012 SP3, 2014 SP2, 2016 SP1. Estimated RowsRead (Estimeret antal rækker, der skal læses i SSMS) egenskab er tilgængelig fra SQL Server 2016 SP1.
IO-statistik og operatørudførelsestid
Der er flere meget nyttige egenskaber etableret i SQL Server 2016, 2014 SP2 og tilgængelige i den faktiske forespørgselsplan. De er IO-metrikker (hvis en operatør har IO) – Faktisk IO-statistik, CPU- og eksekveringstidsmålinger – Faktisk tidsstatistikker og hukommelsesmetrikker (fra 2016 SP1, hvis en operatør kræver hukommelse).
Egenskaberne inkluderer følgende nye metrikker, der kan opdeles i tråde i tilfælde af parallelplanen:
- Faktiske forløbne forløb
- Faktiske CPU'er
- Faktiske scanninger
- ActualLogicalReads
- Faktiske fysiske læsninger
- ActualReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Som du kan se fra listen ovenfor, kan du hente omfattende information om udførelsen af en given operatør, forbrugt IO og hukommelse. I de sidste versioner af SSMS er disse metrics repræsenteret i egenskabsvinduet. Hvis du bruger en gammel version af SSMS, kan du hente dem ved at åbne planen som XML. Efter min mening er der nu alt for at vise procenter, ikke efter estimerede omkostninger, men efter faktiske forløbne ressourcer (jeg oprettede et forslag på Connect. Så hvis du kan lide ideen, så stem venligst for det).
Oplysninger om aktiverede sporingsflag
Sporingsflag i SQL Server er specielle 'switches' fra standardserveradfærden til en anden adfærd. Fra SQL Server 2014 SP2 og 2016 SP1 er oplysninger om aktiverede sporingsflag tilgængelige i TraceFlags-egenskaben for det specifikke element. Den kan inkludere op til 100 samtidigt aktiverede flag i det øjeblik, forespørgslen opbygges.
Information om dataspild til tempdb
Nogle planoperatører, for eksempel, såsom Sorter eller Hash Match, kræver hukommelse under udførelse af forespørgsler. Hukommelsesvolumen beregnes dog på tidspunktet for kompilering. På grund af forskellige årsager (f.eks. forkert evaluering af formodede antal eller rækker), kan hukommelsesvolumen beregnes forkert. Hvis der er allokeret mindre hukommelse, end det er nødvendigt for udførelse, bliver serveren nødt til at spilde data til tempdb. Det forsinker udførelsen af forespørgsler. Forsigtighed omkring en sådan situation blev introduceret i server 2012, men fra SQL Server 2012 SP3, 2014 SP2, 2016 er diagnosticeringsoplysningerne blevet udvidet, og nu inkluderer den mængden af spildt data og læste data. Så du kan vurdere problemet og tage de rigtige foranstaltninger.
Konklusion
Udførelsesplanen indeholder masser af nyttig information, den faktiske forespørgselsplan indeholder endnu flere oplysninger, og den faktiske forespørgselsplan i de sidste versioner af SQL Server er blot en mine af nyttig information. Denne artikel er ikke beregnet til at lære nogen at analysere forespørgselsplaner. I stedet overvejede jeg de mest interessante planejendomme, herunder nye ejendomme og gamle, men undervurderede. Jeg håber, at denne artikel vil hjælpe dig næste gang, når du skal analysere forespørgselsydeevnen.
Artiklen blev oversat af Codingsight-teamet med tilladelse fra forfatteren.
Nyttigt værktøj:
dbForge Query Builder til SQL Server – giver brugerne mulighed for hurtigt og nemt at bygge komplekse SQL-forespørgsler via en intuitiv visuel grænseflade uden manuel kodeskrivning.