Vipppunkten är en term som jag först hörde användas av SQL Servers prestationsjusteringsguru och sedan länge SentryOne Advisory Board-medlem Kimberly Tripp – hon har en fantastisk bloggserie om det här. Tipppunkten är tröskeln vid vilken en frågeplan kommer att "tippa" från att söka ett icke-täckande icke-klustrat index till att skanna det klustrade indexet eller högen. Den grundläggande formeln, som inte är en hård och snabb regel eftersom det finns flera andra påverkande faktorer, är denna:
- En klustrad index (eller tabell) genomsökning sker ofta när beräknade rader överstiger 33 % av antalet sidor i tabellen
- En icke-klustrad sök-plusnyckelsökning sker ofta när beräknade rader är under 25 % av sidorna i tabellen
- Mellan 25 % och 33 % kan det gå åt båda hållen
Observera att det finns andra "vändpunkter" för optimeraren, till exempel när en täckning index tippar från en sökning till en genomsökning, eller när en fråga går parallellt, men den vi fokuserar på är det icke-täckande icke-klustrade indexet scenario eftersom det tenderar att vara det vanligaste – det är svårt att täcka varje fråga! Det är också potentiellt farligast för prestanda, och när du hör någon hänvisa till SQL Server-indexets tipppunkt, är det vanligtvis vad de menar.
The Tipping Point i tidigare versioner av Plan Explorer
Plan Explorer har tidigare visat nettoeffekten av vändpunkten när parametersniffning pågår i indexanalys fliken, specifikt via Uppskattad(imerad) operation raden i Parametrar ruta:
Den uppskattade operationen för de kompilerade parametrarna och körtidsparametrarna, baserat på antalet rader
Om du ännu inte har utforskat modulen Indexanalys rekommenderar jag dig att göra det. Även om plandiagrammet och andra Plan Explorer-funktioner är fantastiska, ärligt talat, är Indexanalys där du bör spendera större delen av din tid när du ställer in frågor och index. Kolla in Aaron Bertrands djupgående genomgång av funktioner och scenarier här, och en bra handledning av Devon Leann Wilson här.
Bakom kulisserna gör vi tipping point-matten och förutsäger indexoperationen (sök eller skanning) baserat på beräknade rader och antal sidor i tabellen för både de kompilerade parametrarna och körtidsparametrarna, och färgkodar sedan de associerade cellerna så att du kan snabbt se om de matchar. Om de inte gör det, som i exemplet ovan, kan det vara en stark indikator på att du har problem med parametersnuffning.
Statistikhistogrammet diagram återspeglar fördelningen av värden för den inledande nyckeln i indexet med kolumner för lika rader (orange) och intervallrader (bricka). Det här är samma värden som du får från DBCC SHOW_STATISTICS eller sys.dm_db_stats_histogram . De delar av distributionen som träffas av både de kompilerade parametrarna och körtidsparametrarna är markerade för att ge dig en ungefärlig uppfattning om hur många rader som är involverade för varje. Välj helt enkelt antingen Kompilerat värde eller Runtime Value kolumn för att se det valda intervallet:
Histogramdiagram som visar intervallet som träffas av körtidsparametrarna
Nya kontroller och bilder
Ovanstående funktioner var trevliga, men ett tag har jag känt att det fanns mer vi kunde göra för att göra saker tydligare. Så, i den senaste versionen av Plan Explorer (2020.8.7) har botten av rutan Parametrar några nya kontroller med tillhörande grafik på histogramdiagrammet:
Nya kontroller för histogrambilder
Observera att histogrammet som visas som standard är för indexet som används av frågan för att komma åt den valda tabellen, men du kan klicka på någon annan indexrubrik eller tabellkolumn i rutnätet för att se ett annat histogram.
Tipping Point Range
Tipping Point Range kryssrutan växlar det ljusröda bandet som visas på histogramdiagrammet:
Växla för band för tipppunktsintervall
Om de uppskattade raderna ligger under detta intervall, kommer optimeraren att gynna en sökning + uppslag, och ovanför den en tabellskanning. Inom intervallet är någons gissning.
Uppskattad(imated)/Faktisk rad
Uppskattade/faktiska rader kryssrutan växlar visning av uppskattade rader (från de kompilerade parametrarna) och faktiska rader (från körtidsparametrarna). Pilarna i diagrammet nedan illustrerar förhållandet mellan denna kontroll och de associerade elementen:
Växla för uppskattade och faktiska rader på histogramdiagrammet
I det här exemplet är det tydligt att de uppskattade raderna ligger under tipppunkten och att de faktiska raderna som returneras är ovanför det, vilket återspeglas i skillnaden mellan de angivna uppskattade och faktiska operationerna (Seek vs Scan). Detta är klassisk parametersniffning, illustrerad!
I ett framtida inlägg kommer jag att gå igenom hur detta korrelerar med vad du ser på plandiagrammet och rutnätet. Under tiden, här är en Plan Explorer-sessionsfil som innehåller det här exemplet (sök-till-sök-parametersniffning) samt ett skanna-till-sök-exempel. Båda utnyttjar den utökade WideWorldImporters-databasen.
Räckviddsrader eller Genomsnittligt intervallrader
Tidigare versioner av Plan Explorer staplade de lika raderna och intervallraderna i en kolumn för att representera det totala antalet rader i en histogramskopa. Detta fungerar bra när du har ett ojämlikhets- eller intervallpredikat som visas ovan, men för likhetspredikat är det inte så meningsfullt. Vad du verkligen vill se är de genomsnittliga intervallraderna eftersom det är vad optimeraren kommer att använda för uppskattningen. Tyvärr fanns det inget sätt att få det här.
I det nya Plan Explorer-histogrammet, istället för en staplad kolumnserie använder vi nu klustrade kolumner med lika rader och intervallrader sida vid sida, och du styr om total- eller medelintervallraderna ska visas med hjälp av intervallrader/genomsnittlig intervallrader väljare. Mer om detta snart...
Avsluta
Jag är verkligen exalterad över dessa nya funktioner, och jag hoppas att du tycker att de är användbara. Prova dem genom att ladda ner den nya Plan Explorer. Detta var bara en kort introduktion, och jag ser fram emot att täcka några olika scenarier här. Låt oss som alltid veta vad du tycker!