Introduktion
SQL-frågan beskriver det förväntade resultatet, inte sättet att få resultatet. Uppsättningen av specifika steg som servern måste ta för att returnera resultatet kallas för query execution plan. Planen är byggd av optimeraren. Valet av en plan påverkar exekveringshastigheten, vilket gör den till en av de viktigaste delarna av analysen av frågeprestandaproblem.
Utförandeplan omfattar verksamhetsutövare och deras egenskaper som är sammanlänkade med varandra i form av trädstrukturen. Varje operatör ansvarar för en separat logisk eller fysisk operation. Sammantaget säkerställer de resultatet som beskrivs i frågetexten. Inuti trädet representeras operatörer av klassobjekten i SQL Servers minne. Serveranvändare (det vill säga du och jag) ser beskrivningen genererad i XML-format med ett specifikt schema, som visas grafiskt av SQL Server Management Studio-miljön (SSMS).
Det finns många olika planoperatörer och ännu fler fastigheter. Dessutom dyker det upp nya då och då. Denna artikel vågar inte beskriva alla möjliga variationer av operatörer. Istället skulle jag vilja dela med mig av de mest intressanta tilläggen i detta ämne och påminna om några gamla men användbara element.
Serverversion
Ibland kan du hitta förfrågningar om serverversionen på forumen, även om frågeplanen tillhandahålls i rätt format (XML). Istället kan du spara tid och öppna exekveringsplanen som XML. Och det första elementet som beskriver planen kommer att visa dig serverversionen i Build-egenskapen.
Den här metoden tillåter inte att man hämtar fullständig information om serverutgåvan, men i de flesta fall räcker det för att förstå vad vi sysslar med.
Antal tabellrader
Den andra vanliga frågan är "Hur många rader innehåller din tabell?". Denna information kan också hämtas från frågeplanen (från serverversion 2008). För detta måste vi välja dataåtkomstoperatören (Skanna eller Sök) för en tabell i fråga och ta en titt på TableCardinality fast egendom. Det finns ytterligare en intressant egenskap, Uppskattad radstorlek, för specifikation av radstorlek och ungefärlig utvärdering av tabellen eller indexstorleken (förutsatt att tabellen inte är komprimerad).
Jag skulle vilja notera att detta inte är ett reellt antal rader i en tabell, utan data från objektstatistiken. Dessa data är dock grunden för de beslut som optimeraren fattar när den bygger en fråga.
Kontext
Frågeplanen sparar anmärkningsvärda SET-inställningar som den byggdes för. För att se inställningarna måste du välja ett rotelement i planen och utöka Ange alternativ fast egendom. Till exempel kan vi ta reda på om planen byggdes med ARITHABORT alternativet aktiverat (skillnaden mellan den här inställningen leder ofta till två olika planer och situationer med dålig parametersniffning).
Antal processorer
Vi kan hämta antalet processorer som är tillgängliga för optimeraren. För detta måste vi öppna OptimizerHardwareDependentPropertie s -> EstimatedAvailableDegreeOfParallelism parametern i samma rotelement och multiplicera den med 2. Om bara en processor är tillgänglig behövs ingen multiplicera.
2*2 =4, 4 processorer är tillgängliga. Jag har faktiskt en processor med fyra kärnor på min dator, och alla fyra kärnorna är tillgängliga för servern. Denna information kan hjälpa dig att upptäcka maskinen på vilken planen skapades.
Cardinality Estimator-version
Från och med SQL Server 2014 har flera versioner av Cardinality Estimator (RU) blivit tillgängliga. Denna mekanism påverkar de flesta beslut som optimeraren tar när du väljer en plan. Du kan hämta versionen av Cardinality Estimator från CardinalityEstimationModelVersion egenskapen för rotoperatorn.
- 0 – SQL Server <=2012
- 120 – SQL Server 2014
- 130 – SQL Server 2016
- 140 – SQL Server vNext
Frågekörningstid och väntetid
Från och med SQL Server 2016 SP1 innehåller den faktiska frågeplanen information om exekveringstid och processortid. För att hämta denna data måste du utöka QueryTimeStats egenskapen i rotelementet och visa värdena för CpuTime och ElapsedTime . Vi behöver inte aktivera insamling av körningstid eller fråga "hur länge kördes frågan?" längre – all denna information ingår i planen.
Den andra anmärkningsvärda förbättringen är topp 10 av de längsta väntetiderna under utförande av en fråga. För detta måste vi utöka WaitStats egenskap i rotelementet. Det här tillägget gör det möjligt att få mer exakta orsaker till långsam frågekörning och förenklar diagnostiken avsevärt.
Parametertyper
Parameterlistan egenskap, som listar parametrar som används i frågan, fanns i planen för länge sedan. Men från och med SQL Server 2016 SP1, Parameter Data Type egenskapen har lagts till i parameterdefinitionen. Den här egenskapen lagrar datatypen för parametern. Det kan vara användbart för att förstå problem med typkonverteringen.
Antal rader som ska läsas och uppskattat antal rader som ska läsas
Utförandeplanen inkluderar två mycket viktiga egenskaper, Faktiskt antal rader och uppskattat antal rader. Dessa egenskaper innehåller information om antalet rader som returneras av dataläsoperatorn, men inte antalet rader som den faktiskt har läst. Egenskaperna Antal rader som ska läsas och uppskattat antal rader som ska läsas svarar på denna fråga och gör det möjligt att hämta antalet rader som servern faktiskt har läst eller kommer att läsa. Egenskapen ActualRowsRead (Antal rader lästa i SSMS) är tillgänglig från SQL Server 2012 SP3, 2014 SP2, 2016 SP1. EstimatedRowsRead Egenskapen (uppskattat antal rader som ska läsas i SSMS) är tillgänglig från SQL Server 2016 SP1.
IO-statistik och operatörsexekveringstid
Det finns flera mycket användbara egenskaper etablerade i SQL Server 2016, 2014 SP2 och tillgängliga i själva frågeplanen. De är IO-statistik (om en operatör har IO) – Faktisk IO-statistik, CPU- och körtidsstatistik – Statistik över faktisk tid och minnesstatistik (från 2016 SP1, om en operatör kräver minne).
Egenskaperna inkluderar följande nya mått som kan delas upp i trådar vid parallellplanen:
- Faktiska förflutna
- Faktiska CPU:er
- ActualScans
- ActualLogicalReads
- ActualPhysicalReads
- ActualReadAheads
- ActualLobLogicalReads
- ActualLobPhysicalReads
- ActualLobReadAheads
- InputMemoryGrant
- OutputMemoryGrant
- UsedMemoryGrant
Som du kan se från listan ovan kan du hämta omfattande information om exekveringen av en given operatör, förbrukad IO och minne. I de senaste versionerna av SSMS är dessa mätvärden representerade i egenskapsfönstret. Om du använder en gammal version av SSMS kan du hämta dem genom att öppna planen som XML. Enligt min åsikt finns det nu allt för att visa procent, inte efter beräknad kostnad, utan efter faktiska resurser som förflutit (jag skapade ett förslag på Connect. Så om du gillar idén, vänligen rösta på det).
Information om aktiverade spårningsflaggor
Spårningsflaggor i SQL Server är speciella "switchar" från standardserverns beteende till något annat beteende. Från och med SQL Server 2014 SP2 och 2016 SP1 är information om aktiverade spårningsflaggor tillgänglig i egenskapen TraceFlags för det specifika elementet. Den kan inkludera upp till 100 samtidigt aktiverade flaggor vid det ögonblick då frågan skapas.
Information om dataspill till tempdb
Vissa planoperatörer, till exempel, såsom Sortera eller Hash Match, kräver minne under exekvering av en fråga. Minnesvolymen beräknas dock vid kompileringsögonblicket. På grund av olika orsaker (t.ex. felaktig utvärdering av förmodat antal eller rader), kan minnesvolymen beräknas felaktigt. Om mindre minne tilldelas än vad som krävs för exekvering, måste servern spilla data till tempdb. Det saktar ner exekveringen av frågor. Försiktighet inför en sådan situation infördes i server 2012, men från och med SQL Server 2012 SP3, 2014 SP2, 2016 har den diagnostiska informationen utökats, och nu inkluderar den volymen av utspilld data och läst data. Så du kan utvärdera problemet och vidta lämpliga åtgärder.
Slutsats
Exekveringsplanen innehåller massor av användbar information, den faktiska frågeplanen innehåller ännu mer information, och den faktiska frågeplanen i de senaste versionerna av SQL Server är bara en gruva av användbar information. Den här artikeln är inte avsedd för att lära någon att analysera frågeplaner. Istället ansåg jag de mest intressanta planfastigheterna, inklusive nya fastigheter och gamla, men underskattade. Jag hoppas att den här artikeln kommer att hjälpa dig nästa gång du kommer att behöva analysera frågeprestanda.
Artikeln översattes av Codingsight-teamet med tillstånd från författaren.
Användbart verktyg:
dbForge Query Builder för SQL Server – tillåter användare att snabbt och enkelt bygga komplexa SQL-frågor via ett intuitivt visuellt gränssnitt utan manuell kodskrivning.