Inleiding
SQL-query beschrijft het verwachte resultaat, niet de manier om het resultaat te krijgen. De reeks specifieke stappen die de server moet nemen om het resultaat te retourneren, wordt het query-uitvoeringsplan genoemd. Het plan wordt gebouwd door de optimizer. De selectie van een plan heeft invloed op de uitvoeringssnelheid, wat het een van de belangrijkste elementen van de probleemanalyse van de queryprestaties maakt.
Uitvoeringsplan omvat operators en hun eigenschappen die met elkaar in verband staan in de vorm van de boomstructuur. Elke operator is verantwoordelijk voor een afzonderlijke logische of fysieke operatie. Alles bij elkaar zorgen ze voor het resultaat dat in de vraagtekst wordt beschreven. Binnen de boom worden operators vertegenwoordigd door de klassenobjecten in het geheugen van SQL Server. Servergebruikers (dat wil zeggen, jij en ik) zien de beschrijving gegenereerd in XML-formaat met een specifiek schema, dat grafisch wordt weergegeven door de SQL Server Management Studio (SSMS)-omgeving.
Er zijn veel verschillende planoperators en nog meer eigenschappen. Bovendien komen er af en toe nieuwe bij. Dit artikel durft niet alle mogelijke variëteiten van operators te beschrijven. In plaats daarvan zou ik graag de meest interessante toevoegingen in dit onderwerp willen delen en enkele oude maar nuttige elementen willen herinneren.
Serverversie
Soms kun je verzoeken om de serverversie op de forums vinden, zelfs als het queryplan in het juiste formaat (XML) wordt verstrekt. In plaats daarvan kunt u tijd besparen en het uitvoeringsplan openen als XML. En het eerste element dat het plan beschrijft, toont u de serverversie in de eigenschap Build.
Met deze methode kan geen volledige informatie over de servereditie worden opgehaald, maar in de meeste gevallen is het voldoende om te begrijpen waar we mee te maken hebben.
Aantal tabelrijen
De tweede veelgestelde vraag is "Hoeveel rijen bevat uw tabel?". Deze informatie kan ook uit het queryplan worden gehaald (vanaf serverversie 2008). Hiervoor moeten we de operator voor gegevenstoegang (Scan of Seek) van een betreffende tabel selecteren en de TableCardinality bekijken eigendom. Er is nog een interessante eigenschap, Geschatte rijgrootte, voor specificatie van de rijgrootte en geschatte evaluatie van de tabel of indexgrootte (aangezien de tabel niet is gecomprimeerd).
Ik wil graag opmerken dat dit geen echt aantal rijen in een tabel is, maar gegevens uit de objectstatistieken. Deze gegevens vormen echter de basis voor de beslissingen die de optimizer neemt bij het bouwen van een query.
Context
Queryplan slaat opmerkelijke SET-instellingen op waarvoor het is gebouwd. Om de instellingen te bekijken, moet u een hoofdelement in het plan selecteren en de Opties instellen uitvouwen eigendom. We kunnen bijvoorbeeld zien of het plan is gebouwd met de ARITHABORT optie ingeschakeld (verschil van deze instelling leidt vaak tot twee verschillende plannen en situaties met slecht parametersnuiven).
Aantal CPU's
We kunnen het aantal processors achterhalen dat beschikbaar is voor de optimizer. Hiervoor moeten we de OptimizerHardwareDependentPropertie . openen s -> EstimatedAvailableDegreeOfParallelism parameter in hetzelfde wortelelement en vermenigvuldig dit met 2. Als er maar één processor beschikbaar is, is vermenigvuldigen niet nodig.
2*2 =4, 4 CPU's zijn beschikbaar. Ik heb inderdaad een 4-core processor op mijn computer, en alle 4 cores zijn beschikbaar voor de server. Deze informatie kan u helpen om de machine te detecteren waarop het plan is gegenereerd.
Versie kardinaliteitschatter
Vanaf SQL Server 2014 zijn er verschillende versies van Cardinality Estimator (RU) beschikbaar gekomen. Dit mechanisme is van invloed op de meeste beslissingen die de optimizer neemt bij het selecteren van een plan. U kunt de versie van Cardinality Estimator ophalen uit de CardinalityEstimationModelVersion eigenschap van de root-operator.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Uitvoertijd en wachttijd voor query's
Vanaf SQL Server 2016 SP1 bevat het eigenlijke queryplan informatie over uitvoeringstijd en processortijd. Om deze gegevens op te halen, moet u de QueryTimeStats . uitvouwen eigenschap in het root-element en bekijk de waarden van CpuTime en ElapsedTime . We hoeven het verzamelen van de uitvoeringstijd niet in te schakelen of te vragen "hoe lang is de query uitgevoerd?" meer - al deze informatie is opgenomen in het plan.
De tweede opmerkelijke verbetering is de top 10 van de langste wachttijden tijdens het uitvoeren van query's. Hiervoor moeten we deWachtstatistieken . uitbreiden eigenschap in het root-element. Deze toevoeging maakt het mogelijk om preciezere redenen te krijgen voor de trage uitvoering van query's en vereenvoudigt de diagnostiek aanzienlijk.
Parametertypen
De Parameterlijst eigenschap, die de parameters weergeeft die in de query worden gebruikt, bestond al lang in het plan. Echter, vanaf SQL Server 2016 SP1 is het Parameter Data Type eigenschap is toegevoegd aan de parameterdefinitie. Deze eigenschap slaat het gegevenstype van de parameter op. Het kan handig zijn om problemen met de typeconversie te begrijpen.
Aantal gelezen rijen en geschat aantal te lezen rijen
Het uitvoeringsplan omvat twee zeer belangrijke eigenschappen, het werkelijke aantal rijen en het geschatte aantal rijen. Deze eigenschappen bevatten informatie over het aantal rijen dat is geretourneerd door de operator voor het lezen van gegevens, maar niet over het aantal rijen dat daadwerkelijk is gelezen. De eigenschappen Aantal gelezen rijen en Geschat aantal te lezen rijen beantwoorden deze vraag en maken het mogelijk om het aantal rijen op te halen dat de server daadwerkelijk heeft gelezen of gaat lezen. De eigenschap ActualRowsRead (aantal rijen gelezen in SSMS) is beschikbaar vanaf SQL Server 2012 SP3, 2014 SP2, 2016 SP1. De EstimatedRowsRead (Geschat aantal te lezen rijen in SSMS) eigenschap is beschikbaar vanaf SQL Server 2016 SP1.
IO-statistieken en uitvoeringstijd door operators
Er zijn verschillende zeer nuttige eigenschappen vastgelegd in SQL Server 2016, 2014 SP2 en beschikbaar in het eigenlijke queryplan. Dit zijn IO-statistieken (als een operator IO heeft) - Werkelijke IO-statistieken, CPU- en uitvoeringstijdstatistieken - Actuele tijdstatistieken en geheugenstatistieken (vanaf 2016 SP1, als een operator geheugen nodig heeft).
De eigenschappen omvatten de volgende nieuwe metrieken die kunnen worden onderverdeeld in threads in het geval van het parallelle plan:
- ActualElapsedms
- Werkelijke CPUms
- ActualScans
- ActualLogicalReads
- ActualPhysicalReads
- ActualReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Zoals u in de bovenstaande lijst kunt zien, kunt u uitgebreide informatie ophalen over de uitvoering van een bepaalde operator, verbruikte IO en geheugen. In de laatste versies van SSMS worden deze metrieken weergegeven in het eigenschappenvenster. Als u een oude versie van SSMS gebruikt, kunt u deze ophalen door plan als XML te openen. Naar mijn mening is er nu alles om procenten weer te geven, niet op basis van geschatte kosten, maar op basis van werkelijk verbruikte middelen (ik heb een suggestie gemaakt bij Connect. Dus als je het idee leuk vindt, stem er dan voor).
Informatie over ingeschakelde traceervlaggen
Traceervlaggen in SQL Server zijn speciale 'switches' van het standaard servergedrag naar ander gedrag. Vanaf SQL Server 2014 SP2 en 2016 SP1 is informatie over ingeschakelde traceervlaggen beschikbaar in de eigenschap TraceFlags van het specifieke element. Het kan maximaal 100 gelijktijdig geactiveerde vlaggen bevatten op het moment dat de query wordt gemaakt.
Informatie over gegevensverlies naar tempdb
Sommige planoperators, zoals Sort of Hash Match, hebben geheugen nodig tijdens het uitvoeren van query's. Het geheugenvolume wordt echter berekend op het moment van compilatie. Om verschillende redenen (bijvoorbeeld onjuiste evaluatie van verondersteld aantal of rijen), kan het geheugenvolume onjuist worden berekend. Als er minder geheugen wordt toegewezen dan nodig is voor uitvoering, moet de server gegevens naar tempdb overdragen. Het vertraagt de uitvoering van query's. Voorzichtigheid over een dergelijke situatie werd geïntroduceerd in server 2012, maar vanaf SQL Server 2012 SP3, 2014 SP2, 2016 is de diagnostische informatie uitgebreid en omvat nu het volume van gemorste gegevens en gelezen gegevens. U kunt het probleem dus evalueren en de juiste maatregelen nemen.
Conclusie
Het uitvoeringsplan bevat veel nuttige informatie, het werkelijke queryplan bevat nog meer informatie en het werkelijke queryplan in de laatste versies van SQL Server is slechts een schat aan nuttige informatie. Dit artikel is niet bedoeld om iemand te leren queryplannen te analyseren. In plaats daarvan heb ik de meest interessante planeigenschappen overwogen, inclusief nieuwe en oude, maar ondergewaardeerde. Ik hoop dat dit artikel u zal helpen de volgende keer dat u de prestaties van de zoekopdracht moet analyseren.
Het artikel is vertaald door het Codingsight-team met toestemming van de auteur.
Handig hulpmiddel:
dbForge Query Builder voor SQL Server – stelt gebruikers in staat om snel en eenvoudig complexe SQL-query's te bouwen via een intuïtieve visuele interface zonder handmatig code schrijven.