Het wordt altijd aangemoedigd om bij het schrijven van query's of SQL Server-databasecode (procedures en views) kennis te nemen van het uitvoeringsplan. Hier zijn verschillende redenen voor. Ten eerste kan de optimizer een plan kiezen dat u niet verwacht. U kunt bijvoorbeeld een grote tabel indexeren voordat u deze aan een kleinere tabel koppelt. Ten tweede moet worden overwogen hoe deze query zal presteren in de komende maanden of jaren als de query's worden uitgevoerd in een nieuw systeem met kleine tabellen die zullen groeien. En tot slot, maar vooral, hoe snel is deze query en hoeveel bronnen gebruikt deze. Het laatste punt lijkt misschien niet zo belangrijk, je zou kunnen denken dat zolang het minder dan 3 seconden duurt, dat goed genoeg is, maar als het in <1 seconde zou kunnen werken, zou dat niet beter zijn? Als uw databases in de cloud worden gehost, kan het verminderen van resources u ook geld besparen.
Veel gevallen van SQL-optimalisatie komen normaal gesproken voort uit een probleem dat wordt gedetecteerd door de eindgebruiker of uw monitoringsoftware. "Waarom duurt het 30 minuten om dit rapport te genereren?", "Wat veroorzaakt die piek in I/O-wacht" of "Waarom duurt het twee keer zo lang om deze taken uit te voeren als vorig jaar?"
In al deze scenario's komt het nog steeds neer op enige kennis over uitvoeringsplannen en de beste manier om de SQL te repareren om de situatie te verbeteren en dit kan erg tijdrovend en niet altijd succesvol zijn.
Laten we een voorbeeld nemen. Dus je schrijft een nieuwe query, voert deze uit en denkt dan:oh, dit duurt te lang.
17 seconden voor 730 rijen, wat moet ik doen?
Laten we eerst het uitvoeringsplan bekijken:
Dit is niet altijd eenvoudig als je moet in- en uitzoomen om het te begrijpen. Het eerste advies is dus om een goede planviewer zoals deze aan te schaffen met het Spotlight Tuning Pack.
De planviewer geeft de belangrijkste informatie weer die we nodig hebben en waar de belangrijkste bewerkingen zijn, evenals eventuele waarschuwingen.
Hier is een voorbeeld:
Er is dus een probleem met deze code, maar wat kunnen we eraan doen?
Nou, eigenlijk best veel. We zouden query-hints kunnen gebruiken, kijken naar het toevoegen van enkele indexen (vergeet niet dat dit van invloed kan zijn op andere query's en DML), stukjes code toevoegen die de resultatenset niet veranderen, maar de optimalisatie beïnvloeden om een ander plan te genereren en kleine trucs om stop de optimizer met het overwegen van een bepaalde index die hij gebruikt en genereer misschien een nieuw plan. Maar dit is allemaal vallen en opstaan en het kost veel tijd om het handmatig te doen.
Door de toepassing Spotlight Extensions aan SSMS toe te voegen en u te abonneren op het Spotlight Tuning Pack, kunnen we de optimalisatiefunctie in het Tuning Pack al het harde werk voor ons laten doen.
Het is je misschien opgevallen in de eerste schermafbeelding dat wanneer de functie is ingeschakeld, deze automatisch detecteert dat optimalisatie mogelijk is:
Klik op Analyse bekijken
U kunt vervolgens op de knop Optimaliseren klikken en de optimalisatie-engine analyseert de code en begint herschrijfregels toe te passen die de syntaxis van de SQL zullen veranderen, waardoor alternatieven worden geboden die dezelfde resultatenset bieden, en deze vervolgens testen zodat we kunnen zien of er een alternatieve uitvoering is plannen zijn sneller en waarom. De regels worden in combinaties toegepast, zodat de mogelijke alternatieven meer dan 100 kunnen zijn. De tool toont u echter alleen alternatieven die sneller zijn dan het origineel.
Dit proces wordt op de achtergrond uitgevoerd en bespaart u enorm veel tijd als u dit handmatig probeert te doen.
En wanneer de resultaten worden getoond, kunt u de alternatieven vergelijken, de codeverschillen bekijken, de plannen vergelijken en de statistieken bekijken.
Dus, terug naar SSMS met mijn nieuwe versie van de query en test het uit.
Succes.
Als dit in een ontwikkelomgeving is, kunt u overwegen de buffercache leeg te maken met DBCC DROPCLEANBUFFERS, om uw query's te testen met een koude buffercache zonder de server af te sluiten en opnieuw op te starten.
Overweeg ook om SET STATISTICS IO ON aan de query toe te voegen voor meer informatie over waarom de querysyntaxis een verschil maakte:
Origineel:
Herschrijven:
En dit kan ook worden bereikt in het Tuning Pack met de functie voor het vergelijken van statistieken:
Dus, met de succesvolle verandering en tevreden eindgebruiker, op naar de volgende vraag. Door de prestaties van afzonderlijke zoekopdrachten voortdurend te verbeteren, verbeteren we de prestaties van de instantie.