Antwoord.

Achtergrond van de vraag:
Vanaf het begin zijn SQL-query's ontworpen als declaratief: "wat te krijgen", niet "hoe te krijgen". De databaseoptimalisator bouwt een uitvoeringsplan (uitvoeringsplan) dat de volgorde van joins, filters, scans en indexgebruik bepaalt.

Probleem:
Zonder begrip van het uitvoeringsplan is het onmogelijk uit te leggen waarom een schijnbaar eenvoudige query te langzaam wordt uitgevoerd en een complexe snel werkt. Een onjuiste planning kan de server uren blokkeren door onnodige operaties of verkeerd indexgebruik.

Oplossing:
Analyse-tools zijn instructies zoals EXPLAIN, EXPLAIN ANALYZE (PostgreSQL), SHOW EXPLAIN (MySQL), Management Studio Execution Plan (SQL Server). Hiermee kun je stap voor stap zien hoe de query exact is uitgevoerd, hoeveel gegevens zijn gelezen, welke index werd gebruikt, waar volledige tabelscans plaatsvonden en waar vertragingen optraden.

Voorbeeld van code:

EXPLAIN ANALYZE SELECT * FROM orders o JOIN customers c ON o.customer_id = c.id WHERE o.status = 'shipped';

Kernkenmerken:

Het plan biedt een gedetailleerde schema van welke operatie in welke volgorde door de database is uitgevoerd.
Je kunt zien waar een index scan werd gebruikt en waar een table scan.
Het maakt het mogelijk om knelpunten voor optimalisatie te identificeren en de hypothese over de impact van het herschrijven van de query op de prestaties te controleren.

Misleidende vragen.

Verbetert het toevoegen van een index altijd de snelheid van de query?

Nee! Een index helpt alleen als de filtering op zijn veld het aantal teruggegeven rijen aanzienlijk beperkt. Als de meeste records voldoen aan de verklaring, kan de optimalisator de index negeren.

Voorbeeld:

-- Veld 'gender' heeft slechts twee waarden -- index helpt niet
CREATE INDEX idx_gender ON people(gender);
SELECT * FROM people WHERE gender = 'M';

Hangt de volgorde van tabellen in JOIN af van het resultaat?

Nee, de uiteindelijke gegevens zullen hetzelfde zijn, maar de optimalisator kan de volgorde van de uitvoering van joins aanpassen om de prestaties te verbeteren. Maar als een specifieke JOIN is geschreven of hints zoals "JOIN HINT" worden gebruikt, kan de volgorde de efficiëntie van de uitvoering beïnvloeden.

Waarom analyseren we "Estimated rows" en "Actual rows" in het uitvoeringsplan?

Het verschil tussen hen kan aangeven dat de statistieken van de tabellen verouderd of niet in overeenstemming zijn met de werkelijkheid, en dat het gekozen plan niet optimaal is - statistieken moeten worden bijgewerkt of de structuur van de query moet worden heroverwogen.

-- PostgreSQL
ANALYZE table_name; -- statistieken bijwerken

Typische fouten en antipatterns

Het uitvoeringsplan wordt niet bekeken bij problemen: proberen te optimaliseren "in het duister"
Het toevoegen van onnodige/ongeschikte indexen voor "versnelling", wat alleen de gegevensveranderingen vertraagt
Statistieken van tabellen worden niet bijgewerkt
Query's worden ontworpen zonder rekening te houden met hoe ze door de optimalisator worden uitgevoerd

Voorbeeld uit het leven

Negatief geval

Analisten klaagden lange tijd over het "vastlopen" van rapporten. Een query met vijf JOIN's duurde 25 minuten. Het bleek dat een plan was gekozen met een volledige scan van een enorme tabel in plaats van een index scan, de indexen waren niet op de juiste velden, en de statistieken waren een jaar niet bijgewerkt.

Voordelen:

Eenvoudige ondersteuning, minimalisatie van indexen

Nadelen:

Query werkte langzaam, er werd veel menselijke arbeid verbruikt
Ontevredenheid van gebruikers
Belastingen op de server

Positief geval

We voerden een analyse van het uitvoeringsplan uit, voegden een index toe op het feitelijk filterende veld en werkten de statistieken bij. De tijd van de query verminderd tot 20 seconden. De belasting op de server werd verlaagd met een orde van grootte.