Het is gemakkelijk om te beginnen met sleutelen aan de optimalisatie van SQL-query's. U opent SQL Server Management Studio (SSMS), bewaakt de wachttijd, bekijkt het uitvoeringsplan, verzamelt objectinformatie en begint SQL te optimaliseren totdat u een nauwkeurig afgestelde machine gebruikt.
Als je er goed genoeg in bent, behaal je een snelle overwinning en keer je terug naar je regelmatig geplande chaos. Maar als je het verkeerde aanpast, of het goede in de verkeerde richting aanpast, nou, daar ging je woensdag.
SQL-query-optimalisatie? Waarom denk je dat je het nodig hebt?
Meestal is het een piek in probleemtickets of klachten van gebruikers. “Waarom is het systeem zo traag?” uw gebruikers klagen. "Het duurt een eeuwigheid voordat we deze week onze gebruikelijke rapporten hebben."
Dat is natuurlijk een vrij vage omschrijving. Het zou leuk zijn als ze je konden vertellen:"Het gaat langzaam omdat je een impliciete conversie hebt in regel 62 van CurrentOrderQuery5.sql. De kolom is varchar en je geeft een geheel getal door.' Maar het is niet waarschijnlijk dat uw gebruikers dat detailniveau kunnen zien.
In ieder geval zorgen probleemtickets en telefoontjes voor een actieve statistiek:gemakkelijk te herkennen, gemakkelijk te meten. Wanneer ze binnenstromen, kun je er redelijk zeker van zijn dat het tijd is voor SQL-afstemming.
Maar er zijn andere, passieve statistieken die de behoefte minder duidelijk maken. Dingen zoals dalende verkopen, die te wijten kunnen zijn aan een aantal factoren. Is het omdat pijnlijk trage zoekopdrachten in uw online winkel ervoor zorgen dat uw klanten hun winkelwagentje verlaten? Is het omdat de economie er slecht aan toe is?
Of het kunnen zaken zijn als trage prestaties van SQL Server. Is het omdat een slecht geschreven vraag logische reads door het dak stuurt? Is het omdat de server weinig fysieke bronnen heeft, zoals geheugen en opslag?
In beide scenario's kan SQL-queryoptimalisatie helpen bij de eerste optie, maar niet bij de tweede.
Waarom de juiste oplossing toepassen op het verkeerde probleem?
Voordat u het pad van optimalisatie inslaat, moet u ervoor zorgen dat afstemming de juiste oplossing is voor het juiste probleem.
Het afstemmen van SQL is een technisch proces, maar elke technische stap heeft wortels in goede zakelijke zin. Je zou dagen kunnen besteden om de uitvoeringstijd met een paar milliseconden te verkorten of het aantal logische leesbewerkingen met vijf procent te verminderen, maar is de reductie je tijd waard? Het is waar dat het belangrijk is om aan de eisen van gebruikers te voldoen, maar elke inspanning bereikt uiteindelijk het punt dat het rendement afneemt.
Overweeg deze prestatieproblemen met SQL-query's en de zakelijke context eromheen:
- Aanvaardbare prestaties — Het duurt 10 minuten om een query uit te voeren en de gebruiker wil dat deze binnen één minuut wordt uitgevoerd; dat lijkt een redelijk verschil en een haalbaar doel voor optimalisatie. Als de query echter 's nachts duurt en de gebruiker denkt dat deze binnen een minuut moet worden uitgevoerd, is er mogelijk meer dan een afstemmingsprobleem. Om te beginnen moet u de gebruiker misschien informeren over de hoeveelheid werk die de query daadwerkelijk uitvoert. Voor een ander kan het een probleem zijn met de manier waarop de database is ontworpen of de manier waarop de clienttoepassing is geschreven.
- Hulpprogramma — Stel dat u verantwoordelijk bent voor het beheer van de financiële database in een productiebedrijf. Aan het einde van elke maand klagen gebruikers over slechte prestaties. Je herleidt het probleem tot een reeks eindejaarsrapporten van Accounting die elk uren in beslag nemen en rechtstreeks in een archiefkast terechtkomen die door niemand is onderzocht. In plaats van af te stemmen, leg je het probleem uit aan de bedrijfsleiders en verkrijg je toestemming om de rapporten te verwijderen.
- Tijdverschuiving — Of stel dat diezelfde rapporten belangrijk zijn voor het bestuur, maar niet urgent voor het bedrijf. Als ze eenmaal per week of per maand worden uitgevoerd, kunnen ze worden gepland voor daluren door de dataset vooraf in de cache te plaatsen en de resultaten naar een bestand te sturen. Dat neemt de bottleneck bij de andere zakelijke gebruikers weg en verlost de Accounting-gebruiker van het wachten op de rapportages.
Wanneer u de zakelijke context meeneemt in uw beslissing om te optimaliseren, kunt u prioriteiten stellen en tijd winnen.
Als je SQL-query's optimaliseert, probeer dan SQL-diagrammen
SSMS en de tools die in SQL Server zijn ingebouwd, bieden het meeste van wat u nodig hebt voor effectieve SQL-queryoptimalisatie. Combineer de tools met een methodische aanpak rond de volgende stappen, zoals beschreven in het e-book “The fundamental guide to SQL query optimization“:
- Wachttijd bewaken
- Bekijk het uitvoeringsplan
- Verzamel objectinformatie
- Zoek de rijtafel
- Prestatieremmers identificeren
In stap 4 is het uw doel om de query aan te sturen met de tabel die de minste gegevens retourneert. Wanneer u joins en predikaten bestudeert en eerder in de query filtert in plaats van later, vermindert u het aantal logische leesbewerkingen. Dat is een grote stap in de optimalisatie van SQL-query's.
SQL-diagrammen is een grafische techniek om de hoeveelheid gegevens in de tabellen in kaart te brengen en te bepalen welk filter de minste records oplevert. Eerst bepaalt u welke tabellen de gedetailleerde informatie bevatten en welke tabellen de hoofd- of opzoektabellen zijn. Overweeg het eenvoudige voorbeeld van deze zoekopdracht tegen een universitaire registratiedatabase:
De detailtabel is registratie. Het heeft twee opzoektabellen, leerling en klas. Om een diagram van deze tabellen te maken, tekent u een omgekeerde boom die de detailtabel (bovenaan) met pijlen (of koppelingen) verbindt met de opzoektabellen, als volgt:
Bereken nu het relatieve aantal records dat nodig is voor de join-criteria (dat wil zeggen, de gemiddelde verhouding van rijen die zijn gerelateerd tussen de detailtabel en opzoektabellen). Schrijf de nummers aan elk uiteinde van de pijl. In dit voorbeeld zijn er voor elke student ongeveer 5 records in de registratietabel en voor elke klas zijn er ongeveer 30 records in registratie. Dat betekent dat het nooit nodig zou moeten zijn om lid te worden van meer dan 150 (5×30) records om een resultaat te krijgen voor een enkele leerling of een enkele klas.
Die oefening is handig als uw deelnamekolommen niet zijn geïndexeerd of als u niet zeker weet of ze wel zijn geïndexeerd.
Bekijk vervolgens de filterpredikaten om te zien met welke tabel de query moet worden uitgevoerd. Deze zoekopdracht had twee filters:één op registratie geannuleerd ='N' en de andere op signup_date tussen twee datums. Om te zien hoe selectief het filter is, voert u deze query uit bij registratie:
selecteer count(1) van registratie waar geannuleerd ='N'
EN r.signup_date TUSSEN :beg_date EN :beg_date +1
Het retourneert 4.344 records van de 79.800 totale records in registratie. Dat wil zeggen dat 5,43 procent van de records met dat filter wordt gelezen.
Het andere filter is op klasse:
selecteer count(1) van klasse waar naam =‘ENGLISH 101’
Het retourneert twee records van de 1.000, of 0,2 procent, wat een veel selectiever filter vertegenwoordigt. Klasse is dus de drijvende tafel en degene waarop u uw SQL-afstemming als eerste moet richten.
De stem van de gebruiker
Als u zeker weet dat u SQL-afstemming nodig heeft, biedt 'De fundamentele gids voor het optimaliseren van SQL-query's' meer inzicht. Het leidt u door vijf tips voor het afstemmen van prestaties met kopieer- en plakquery's en casestudy's, waaronder degene die hierboven is beschreven.
U zult waarschijnlijk merken dat de belangrijkste tool voor het optimaliseren van SQL-query's de stem van de gebruiker is. Waarom? Want die stem laat je weten wanneer je moet beginnen met optimaliseren en hij vertelt je wanneer je genoeg hebt geoptimaliseerd. Het kan ervoor zorgen dat je begint te sleutelen aan de versnellingen wanneer dat nodig is en stopt terwijl je nog voor bent.