Het queryplan in SQL Server Management Studio: van trage query naar sneller resultaat

Een queryplan is een visuele of tekstuele weergave van de manier waarop SQL Server jouw query uitvoert. Het toont de stappen (operators) die SQL Server neemt om het resultaat te berekenen, inclusief de volgorde, gebruikte indexen en de hoeveelheid resources die elke stap verbruikt.

In SQL Server Management Studio zijn twee soorten queryplannen:

• Estimated Execution Plan: deze laat zien wat SQL Server denkt te gaan doen, nog voordat de query wordt uitgevoerd.
• Actual Execution Plan: deze toont wat er daadwerkelijk is gebeurd, inclusief statistieken zoals het aantal rijen dat is verwerkt.

Het queryplan helpt je te begrijpen waar je query traag wordt. Denk bijvoorbeeld aan:

• Onnodige table scans, door het ontbreken van indexen.
• Nested loops die veel te vaak worden uitgevoerd.
• Data type mismatches die indexgebruik verhinderen.
• Slechte join-volgorde die leidt tot miljoenen onnodige rijenverwerkingen.

Met deze informatie optimaliseer je gerichter, in plaats van willekeurig indexen toe te voegen op query’s te herschrijven.

Queryplannen zijn makkelijk te raadplegen in SQL Server Management Studio. Wil je een Estimated Execution Plan? Klik dan eerst op het queryvenster in SMSS en vervolgens op “Display Estimated Execution Plan” in de toolbar, of gebruik de sneltoets CRTL + L.

Ben je op zoek naar een Actual Execution Plan? Zet dan eerst de functie Include Actual Execution Plan aan met de sneltoets CRTL + M. Hierna voer je je query uit. Het queryplan verschijnt in een nieuw tabblad naast de resultaten.

In een queryplan zie je een flow die van links naar rechts loopt. Elke ‘node’ (operator) geeft een stap weer, zoals een index seek, table scan, nested loop of hash match. Belangrijke onderdelen om op te letten zijn onder andere:

• Percentage cost: geeft aan welk deel van de totale querytijd aan deze stap wordt toegeschreven.
• Operator type: vertelt welke actie SQL Server uitvoert (zoeken, joinen, sorteren, etc.).
• Tooltips: beweeg met je muis over een operator om extra details te zien, zoals het aantal rijen, gebruikte indexen en geschatte versus werkelijke aantallen.

1. Table scan

Een table scan betekent dat SQL Server de hele tabel moet doorlopen, vaak omdat er geen geschikte index beschikbaar is. Dit kan enorm traag zijn bij grote tabellen. De oplossing? Maak een non-clustered index op de kolom(men) die gebruikt worden in de WHERE-clausule.

2. Key lookup (bookmark lookup)

Een key lookup treedt op wanneer SQL Serer een index gebruikt om een subset van kolommen te vinden, maar vervolgens terug naar de hoofdtabel moet om extra kolommen op te halen. Dit kan leiden tot aanzienlijk extra schrijfactiviteit. Dit los je makkelijk op met een covering index, die alle benodigde kolommen bevat.

3. Mismatch tussen estimated en actual rows

De estimated number of rows kan sterk verschillen van de actual number of rows. Dit kan worden veroorzaakt door verouderde statistieken of slechte schattingen van het aantal records (cardinality estimates). Dit los je op door je statistieken te updaten met:

“UPDATE STATISTICS [TabelNaam];” of “EXEC sp_updatestats;”

4. Inefficiënte joins

SQL Server kiest soms voor een join methode die niet optimaal is, zoals een nested loop waar een merge join beter past. De oplossing: pas query’s aan, optimaliseer indexen of gebruik query hints met mate.

Voor dit stappenplan gebruiken we dit voorbeeld:

SELECT c.CustomerName, o.OrderDate, o.Amount
FROM Customers c
JOIN Orders o ON c.CustomerID = o.CustomerID
WHERE o.OrderDate >= ‘2022-01-01’
ORDER BY o.OrderDate DESC;

Stap 1: open het actual execution plan

Na het uitvoeren zien we bijvoorbeeld:

• Een table scan op ‘Orders’
• Een key lookup op ‘Customers’

Stap 2: analyseer de bottleneck

Orders bevatten miljoenen rijen, maar de WHERE-filter staat op ‘OrderDate’. Zonder index moet SQL Server alles doorlopen.

Stap 3: los op met indexen

Maak een index op ‘OrderDate’, inclusief de benodigde kolommen.

Stap 4: herhaal en controleer het queryplan

Nu zien we in een index seek in plaats van een table scan en de key lookup verdwijnt, dankzij de INCLUDE-kolommen.

1. Gebruik altijd het actual execution plan voor echte prestatieanalyses.
2. Vergelijk voor en na optimalisaties om het effect te meten.
3. Houd statistieken actueel voor nauwkeurige planningen.
4. Gebruik query store (beschikbaar in SQL Server 2016 en nieuwer) om historische queryplannen te bekijken.