Database query performance monitoren: trage queries vinden en oplossen voordat ze je gebruikers raken

Een trage pagina is zelden een trage pagina. Meestal is het een trage query. Je applicatie kan goed ontworpen zijn, je cache kan warm zijn en je frontend kan snel zijn — maar één ontbrekende index of één niet-geoptimaliseerde query kan een verzoek van 50 milliseconden in een timeout van 5 seconden veranderen. Anders dan een harde crash duikt een trage query zelden op in een error log. Hij verslechtert stilletjes de ervaring tot gebruikers vertrekken.

Het monitoren van database query performance is iets anders dan in de gaten houden of je database online is. Beide tellen, maar ze beantwoorden verschillende vragen. Deze gids behandelt de metrics die trage queries blootleggen, de exacte SQL om ze in PostgreSQL en MySQL te vinden, en hoe je de klok rond de wacht houdt.

Twee verschillende vragen: is het online, en is het snel?

Database monitoring splitst zich in twee lagen. Availability monitoring beantwoordt een simpele vraag: kan je applicatie de database nog bereiken, en reageert die binnen redelijke tijd? Query performance monitoring beantwoordt een lastigere vraag: welke queries zijn traag, waarom zijn ze traag, en worden ze erger naarmate de data groeit? Je hebt beide nodig — een database kan perfect bereikbaar zijn terwijl één ontspoorde query je applicatie op de knieën dwingt.

De metrics die er echt toe doen

Voordat je op jacht gaat naar trage queries, bepaal je wat je meet. Deze cijfers scheiden een gezonde database van een database die op het punt staat een incident te veroorzaken:

• Query latency — hoe lang een query duurt, gerapporteerd als p50, p95 en p99. Een p50 van 10 ms met een p99 van 3 seconden betekent dat de meeste gebruikers prima zitten, maar een paar wachten.
• Throughput (QPS) — queries per seconde. Een plotselinge piek kan een nieuwe functie of een luidruchtige buur op gedeelde infrastructuur onthullen.
• Slow query rate — het aandeel queries boven je drempel (bijvoorbeeld 500 ms). Dit is het getal dat je als eerste zou moeten alarmeren.
• Connection pool-verzadiging — als alle verbindingen bezet zijn, wachten nieuwe verzoeken. Hoge wachttijd is vaak een symptoom van trage queries, geen gebrek aan verbindingen.
• Lock- en deadlock-gebeurtenissen — één langlopende transactie kan alles erachter blokkeren.

Trage queries vinden in PostgreSQL

PostgreSQL heeft één tool die het meeste werk doet: de pg_stat_statements-extensie. Die registreert geaggregeerde statistieken voor elke query die draait, waaronder totale tijd, gemiddelde tijd en het aantal aanroepen. Schakel hem één keer in en je krijgt een permanent klassement van je traagste queries.

• Schakel de extensie in: voer CREATE EXTENSION IF NOT EXISTS pg_stat_statements; uit, voeg hem toe aan shared_preload_libraries en herstart de server.
• Rangschik je traagste queries op gemiddelde tijd: SELECT query, calls, mean_exec_time, max_exec_time FROM pg_stat_statements ORDER BY mean_exec_time DESC LIMIT 10;
• Zoom in op één query met EXPLAIN ANALYZE. Die voert de query uit en toont het plan, zodat je ziet of er een index wordt gebruikt of een volledige tabelscan plaatsvindt.
• Let op Seq Scan op een grote tabel, een groot verschil tussen geschatte en werkelijke rijen en dure sorteringen — de drie meest voorkomende oorzaken van trage PostgreSQL-queries.

Trage queries vinden in MySQL

MySQL houdt een slow query log bij die je met een paar instellingen kunt inschakelen. Hij legt elke query vast die langer duurt dan long_query_time, wat het de snelste manier maakt om je ergste overtreders te vinden zonder een monitoring-tool toe te voegen.

• Schakel hem in: SET GLOBAL slow_query_log = 1; SET GLOBAL long_query_time = 1; vind vervolgens het bestand met SHOW VARIABLES LIKE 'slow_query_log_file';
• Inspecteer een plan met EXPLAIN op elke SELECT. Kijk naar de kolom type — ALL betekent een volledige tabelscan, meestal wat er opgelost moet worden.
• Controleer de index-dekking met SHOW INDEX FROM your_table; en zoek naar ontbrekende of ongebruikte indexes.
• Houd Threads_running en Threads_connected in SHOW STATUS in de gaten; een stijgend aantal actieve threads betekent vaak dat trage queries verbindingen openhouden.

Los de oorzaak op, niet het symptoom

Een trage query vinden is slechts de helft van het werk. De oplossingen vallen meestal in een paar bekende categorieën:

• Ontbrekende index — de meest voorkomende oorzaak. Een index op je WHERE- en JOIN-kolommen verandert een volledige scan vaak in enkele milliseconden.
• Het N+1-probleem — een ORM die één query per rij uitvoert in plaats van één voor de hele set. Zoek naar veel kleine, bijna identieke queries in je logs.
• Over-fetching — kolommen selecteren die je nooit gebruikt of rijen die je niet nodig hebt. Beperk resultaten en selecteer alleen wat je toont.
• Verkeerde connection pool-configuratie — een te kleine pool zet verzoeken in de wachtrij; een te grote kan de database overweldigen. Stem hem af op echt verkeer.

Weet het vóór je gebruikers

Tools op query-niveau vertellen je wat er traag is binnen de database. Ze vertellen je niet of je database bereikbaar is vanuit je applicatie, of of een health-check-query nog antwoordt terwijl jij slaapt. Dat is waar externe monitoring om de hoek komt kijken.

Met isthisthing.online maak je een MySQL- of PostgreSQL-Monitor die volgens een schema verbinding maakt met je database, een check uitvoert en de Response Time meet. Als de database stopt met reageren of een check zijn Timeout overschrijdt, krijg je een alert via Email, Slack of je andere kanalen — voordat je gebruikers ooit een fout zien. Gecombineerd met een Incident-tijdlijn en een publieke Status Page verander je "de site werd traag" in een bericht dat je verstuurt in plaats van ontvangt.

Een praktische checklist

• Schakel slow query-logging in (PostgreSQL: pg_stat_statements; MySQL: slow_query_log).
• Vind je 10 traagste queries en voer op elk EXPLAIN ANALYZE uit.
• Los eerst ontbrekende indexes en het N+1-probleem op — die leveren de grootste winst.
• Stel een latency-drempel in en alarmeer daarop, niet alleen op fouten.
• Voeg een MySQL- of PostgreSQL-Monitor toe in isthisthing.online om beschikbaarheid en Response Time van buitenaf te bewaken.
• Controleer query-metrics na elke deployment en elke schema-wijziging.

Trage queries kondigen zichzelf niet aan. Ze stapelen zich op tot de site traag aanvoelt, de database verzadigd raakt en je een storing bestrijdt die je had kunnen voorkomen. Monitor je database van binnen en van buiten, en laat isthisthing.online het je als eerste vertellen.

Maak vandaag je eerste Monitor. Open je gratis account en vang trage queries vóór je gebruikers.