Prestatiebijeenkomst: "PostgreSQL houdt de last niet tegen. » We bespreken een krachtiger lichaam. Iemand is van plan 'EXPLAIN ANALYZE' bij het zoeken naar producten:
Seq Scan op producten (kosten=0..84291 rijen=1 breedte=120) (werkelijke tijd=412..412 ms rijen=50)
Filter: (categorie_id = 7 EN prijs < 100)
Rijen verwijderd door filter: 890000
412 milliseconden voor 50 rijen — 890.000 rijen gefilterd. Samengestelde index (category_id, price) ontbreekt. Het is geen probleem met de cloudprocessor: het is een probleem met het uitvoeringsplan.
EXPLAIN transformeert “het is langzaam” in leesbaar mechanisme. Zonder dit optimaliseer je lukraak – of betaal je voor een grotere instantie om dezelfde hele tabel sneller te scannen.
Een plan lezen: essentiële woordenschat
| Knooppunt | Betekenis | Waarschuw |
|---|---|---|
| Seq-scan | De hele tabel lezen | Grote tafel, weinig rijen geretourneerd |
| Indexscan | Index bladeren | Goed als selectief |
| Bitmapindexscan | Meerdere indexen gecombineerd | Tussentijds compromis |
| Geneste lus | Sluit je aan bij lus | Correct klein × geïndexeerd; slecht indien binnen in sequentiële scan |
| Hash-lid worden | Hashtabel in geheugen | Geheugengebruik monitoren |
| lot | Expliciete sortering | Duur als het volume groot is |
Belangrijkste statistieken in EXPLAIN ANALYZE:
- werkelijke tijd begin..einde per knooppunt
- Geschatte versus werkelijke rijen: slechte statistieken leiden tot een slecht plan
- Buffers gedeelde hit/read - warme versus koude cache
Een geschat/werkelijk verschil vermenigvuldigd met honderd op het aantal rijen → voer
ANALYZE tableuit voordat u een nutteloze index maakt.
Diagnostische workflow in vijftien minuten
- pg_stat_statements inschakelen:
- Kopieer de schuldige vraag →
EXPLAIN (ANALYZE, BUFFERS, TEKSTFORMAAT)... - Identificeer het duurste knooppunt (tijd × lijnen).
- Maak een hypothese: index, join herschrijven, cursorpaging.
- Opnieuw meten; vergelijk mean_exec_time onder echte belasting.
``sql SELECT zoekopdracht, oproepen, mean_exec_time, total_exec_time VAN pg_stat_statements BESTEL OP total_exec_time DESC LIMIT 10; ``
Algemene webvoorbeelden
Zware OFFSET-paging
SELECTEER * UIT artikelen BESTEL OP gepubliceerd_bij DESC OFFSET 50000 LIMIET 20;
→ Paginering met cursor: (published_at, id) < ($last, $id).
*COUNT() op een marketingdashboard**
Volledige scan: gematerialiseerde weergave of gedenormaliseerde teller.
JSONB zonder GIN-index
WHERE data->>'status' = 'actief' → GIN-index of geïndexeerde gegenereerde kolom.
Statistieken en onderhoud
- Regelmatige 'VACUUM ANALYSE' met autovacuümaanpassing.
default_statistics_targethoger op gefilterde kolommen met scheve verdeling.- Na een massale migratie: verouderde statistieken = tijdelijk catastrofale plannen.
Managed PostgreSQL (RDS, Scaleway, OVH): pg_stat_statements kunnen vaak worden geactiveerd; EXPLAIN werkt hetzelfde als zelfgehost. Om te kiezen tussen beheerd en VPS, zie Managed PostgreSQL.
De top: het plan liegt als de statistieken liegen – maar het liegt minder dan de intuïtie
Dit is wat de bijeenkomsten 'laten we de instantie upgraden' vergeten te laten zien.
Teamcultuur: geen “slow query”-tickets gesloten zonder een voor/na-plan — zelfs als de correctie in één indexregel past.
Beslis en ga vooruit zonder blinde vlek
In een halve dag kunt u een diagnostische PostgreSQL-cultuur opzetten:
- Inschakelen pg_stat_statements in productie.
- Analyseer de vijf duurste zoekopdrachten met EXPLAIN ANALYZE in pre-productie.
- Maak een index of herschrijf de query: meet de gecodeerde winst.
- Voer ANALYSE uit na elke grootschalige gegevensimport.
- Correleer langzame applicatieroutes met SQL-query's via uw monitoringtool.
Begin met de query die de meeste totale tijd heeft, en niet de query die het langzaamst is in één keer. Zie Database replicatie en Missing MySQL index voor de parallel aan de MySQL-kant.
Veelgestelde vragen
Wat is het verschil tussen EXPLAIN en EXPLAIN ANALYSE?
EXPLAIN schat het plan zonder de query uit te voeren. EXPLAIN ANALYZE voert het uit en geeft de gemeten tijden weer — voor gebruik in pre-productie of op conservatieve SELECTs, nooit op een enorme DELETE in productie.
Is Seq Scan altijd slecht?
Nee. Op een kleine tafel of wanneer de meeste rijen zijn omgedraaid, kan sequentieel scannen optimaal zijn. Dit is een slecht teken voor een grote tabel waarin weinig rijen worden geretourneerd en veel rijen worden gefilterd.
Hoe herken ik een ontbrekende index?
Zoek naar een sequentiële scan met een groot aantal gefilterde rijen en een dominante uitvoeringstijd. Maak de index, voer EXPLAIN ANALYZE opnieuw uit en vergelijk de voor- en natijden.
Is pg_stat_statements voldoende?
Niet alleen. pg_stat_statements identificeert welke zoekopdrachten de meeste totale tijd in beslag nemen; EXPLAIN legt uit waarom. De twee hulpmiddelen vullen elkaar aan voor een bruikbare diagnose.
Houd op met raden waarom PostgreSQL achterblijft; laat het plan u naar de juiste lijn wijzen.