Een van de beste onderdelen van de SQL taal is dat het gemakkelijk is om te leren en de commando’s te volgen, allemaal dankzij hun eenvoudige syntax.

Maar hier is het addertje onder het gras: niet alle database functies zijn efficiënt. Twee query’s kunnen op elkaar lijken, maar verschillen in de rekentijd, en dit is wat het verschil maakt. Dit is de reden waarom het fine tunen van SQL queries essentieel is.

Als u een organisatie bent die live productie database gebruikt voor rapportage doeleinden en om actuele gegevens te extraheren, is het zelfs belangrijk om SQL queries te optimaliseren om een onnodige belasting van de productie database resources te voorkomen.

Ways to Fine Tune Your SQL Queries

Have a clear set of business requirements before you begin

Eén van de beste manieren om SQL queries te optimaliseren is door de juiste dingen te doen vanaf het eerste begin. Dus, voordat u begint, zorg ervoor dat u de volgende vakjes heeft aangevinkt:

Heeft u de relevante belanghebbenden herkend?

Het is essentieel om alle relevante individuen en teams te betrekken bij het ontwikkelen van de query. Daarnaast is het zelfs belangrijk om het DBA-team te betrekken bij het uitvoeren van query’s voor productiedatabases.

Heeft u uw vereisten geïdentificeerd?

De beste werkwijze om ervoor te zorgen dat aan al uw vereisten wordt voldaan, is het beantwoorden van 5 sets vragen – Wie? Waarom? Wat? Wanneer? Waar?

Zijn de geïdentificeerde vereisten specifiek en to the point?

De productiedatabase speelt een cruciale rol. Het belasten van de database met onduidelijke eisen is veel te riskant. Dus, voordat u een query uitvoert, zorg ervoor dat alle eisen specifiek zijn, en besproken met de juiste belanghebbenden

Beheers de kunst van het maken van de juiste indexen

Prestatie tuning in SQL kan worden gedaan door goed te indexeren, wat zich vertaalt in snellere toegang tot de database op kritieke momenten. Dit is een gebied waar de meeste database beginners tekort schieten. Ze proberen of alles te indexeren of niets te indexeren, en geen van beide benaderingen werkt in hun voordeel.

Dit komt omdat wanneer je helemaal niets indexeert, je queries traag zullen lopen en een onnodige belasting op de database zullen leggen. Aan de andere kant, als je alles indexeert, zullen je insert triggers niet werken zoals verwacht, waardoor je database inefficiënt wordt. De sleutel hier is om de juiste balans te vinden.

Vermijd het gebruik van SELECT*

SELECT* (lees als selecteer alles) wordt vaak gebruikt als een steno om alle gegevens uit een tabel op te vragen. Hoewel deze methode prima werkt voor kleinere tabellen, belast het de database bronnen onnodig wanneer een query wordt uitgevoerd op een tabel met veel velden en rijen.

De beste manier hier is om de velden te definiëren in het SELECT statement om de database te instrueren om alleen de benodigde gegevens te bevragen om aan de einddoelen te voldoen.

Laten we dit beter begrijpen met behulp van een voorbeeld:

Hier volgt een inefficiënte manier, omdat deze query alle gegevens zal ophalen die zijn opgeslagen in de tabel Gebruikers, ongeacht wat u nodig hebt.

SELECT*

FROM Users

Dit is de efficiëntere manier van query’en, omdat het alleen de benodigde informatie ophaalt en voorkomt dat uw database wordt belast.

SELECT LastName, Address, Contact

FROM Users

Gebruik tijdelijke tabellen verstandig

Hoewel tijdelijke tabellen geweldig zijn om te gebruiken, verhogen ze de complexiteit van een query exponentieel. Het wordt sterk aangeraden om het gebruik van tijdelijke tabellen te vermijden als uw code eenvoudig kan worden geschreven.

Maar als u te maken hebt met een opgeslagen procedure die niet kan worden afgehandeld met een enkele query, kan het gebruik van tijdelijke tabellen als tussenpersoon een einde maken aan uw ellende.

Vermijd het gebruik van COUNT()

Een van de veelgebruikte manieren waarop ontwikkelaars controleren of een bepaald record bestaat, is door gebruik te maken van COUNT() in plaats van EXISTS(). COUNT() is inefficiënt omdat het de hele tabel doorzoekt en alle queries telt die aan de voorwaarde voldoen. EXISTS() is daarentegen efficiënter omdat het de lus verlaat zodra het gewenste resultaat is gevonden. Dit draagt bij aan een betere werking, en maakt wegen vrij voor een nettere code.

Vermijd het gebruik van wildcard karakters aan het begin van LIKE pattern

Om uw SQL queries te verfijnen, moet u het gebruik van LIKE pattern op de volgende manier vermijden:

SELECT* FROM Customers WHERE address LIKE ‘%bar%’;

Hier zal de database niet in staat zijn om een geschikte index te gebruiken als deze bestaat vanwege % wildcard. Het systeem begint met het uitvoeren van een volledige tabel scan en dit eist zijn tol op de snelheid. De betere manier om deze query te schrijven is dus:

SELECT* FROM Customers WHERE address LIKE ‘bar%’;

Vermijd het gebruik van SELECT DISTINCT

Hoewel je eenvoudig duplicaten uit een query kunt verwijderen door SELECT DISTINCT te gebruiken, verbruikt deze functie een aanzienlijke hoeveelheid verwerkingskracht. Verder werkt deze query door alle velden in de query te groeperen om afzonderlijke resultaten te presenteren.

De beste manier om dubbele records in uw query te voorkomen, is door meer velden toe te voegen. Op die manier is er geen groepering nodig en zullen de opgehaalde records nauwkeurig zijn.

Hier volgt bijvoorbeeld een inefficiënte manier om dit te doen:

SELECT DISTINCT FirstName, LastName, State

FROM Users

En hier is de efficiënte manier om dit te doen:

SELECT FirstName, LastName, Contact, Address, State, Zip

FROM Users

Bonustip: Bewaar sommige query’s voor de daluren

Om ervoor te zorgen dat uw productiedatabase veilig en gezond blijft, is het sterk aan te bevelen om bepaalde query’s in te plannen voor de daluren, idealiter wanneer het aantal gelijktijdige gebruikers het laagst is. Zo is het midden in de nacht, 3-5 uur ’s nachts is de beste tijd om queries uit te voeren zoals:

• Looping statements
• Looping statements

SELECT* uitvoeren op grote tabellen met meer dan 1 miljoen records

• Nested subqueries
• Wildcard searches
• CROSS JOINs
• SELECT DISTINCT statements

The Wrap Up

Prestatie tuning in SQL is belangrijk om uw database gezond te houden, maar het is niet de gemakkelijkste taak om uit te voeren. De performance van uw SQL queries is afhankelijk van een reeks factoren zoals uw database model, het soort informatie dat u moet ophalen en ga zo maar door.

Het is zeer aan te raden om lastige situaties te voorkomen door een overzicht bij te houden van alle queries die binnenkort afgevuurd gaan worden, en de beste oplossingen te bieden. Als DBA kun je ontwikkelaars ook uitrusten met een data-driven dashboard, zodat ze niet af en toe queries hoeven af te vuren om de essentiële informatie op te halen. Hier is een geweldig artikel over hoe je een SQL-dashboard kunt maken dat gegevens rechtstreeks uit de database haalt.

Wat is jouw mening hierover? Hoe stelt u uw SQL-query’s af? Laat het ons weten.