Black Friday, 10:12 uur: de e-commercesite toont een spinner. MySQL CPU gaat tot 98%, PHP-FPM wacht. Laatste release: vijf dagen geleden. Het team bestelt een VPS-upgrade. Om 11.00 uur voert een ontwikkelaar 'EXPLAIN' uit op het afrekenverzoek - type: ALL, rijen: 2.400.000. Ontbrekende index op (status, create_at) sinds het toevoegen van het filter 'openstaande bestellingen'.
Een ontbrekende wijsvinger schreeuwt niet. Het bouwt zich op tot de dag dat het volume of het verkeer het hoorbaar maakt. Het goede nieuws: de handtekening is leesbaar in het langzame log en EXPLAIN - als je weet hoe je moet kijken voordat je apparatuur koopt.
Handtekeningen van een giftig verzoek
In EXPLAIN signaleert type: ALL een volledige tabelscan. Een enorm aantal 'rijen' vergeleken met het resultaat duidt op een slechte selectiviteit of een ontbrekende index. 'Het gebruik van filesort' en 'Het gebruik van tijdelijk' is duur op ORDER BY en GROUP BY. Herhaalde vergrendelingen duiden op secundaire terughoudendheid.
Langzaam querylogboek inschakelen:
slow_query_log = 1
lange_query_time = 1
log_queries_not_using_indexes = 1
Wanneer rows_examined / rows_sent > 1000 op een HTTP-route, heb je een prioriteitskandidaat.
Van langzame zoekopdracht naar nuttige index
Vereenvoudigd voorbeeld:
SELECTEER * UIT bestellingen
WHERE status = 'in behandeling' EN aangemaakt_at > '2026-01-01'
BESTEL DOOR aangemaakt_op DESC LIMIT 50;
Zonder index: scan van miljoenen rijen. Aangepaste samengestelde index:
CREATE INDEX idx_orders_status_created ON bestellingen (status, create_at);
Volgorde van kolommen: eerst gelijk (status =), reeksen als tweede (created_at >), ORDER BY compatibel indien mogelijk voor een dekkingsscan.
Tools: langzaam loggen met mysqldumpslow, prestatieschema, APM-correlerende route en query. Reproduceer met dicht bij productiegegevens — lege enscenering.
Wanneer niet indexeren
Op een tafel van een paar duizend rijen blijft de scan snel. Een quasi-unieke kolom die al een primaire sleutel heeft, heeft geen duplicaat nodig. Bij massale schrijfbewerkingen kost elke index. Een zeldzaam beheerdersverzoek geeft de voorkeur aan caching of denormalisatie.
Op gedeelde systemen is het trage logboek soms ontoegankelijk: het symptoom “processorlimiet bereikt” zonder details. Op VPS pas je innodb_buffer_pool_size na de indexen aan, niet ervoor.
De bovenkant: de hardware verbergt de zoekopdracht
Voordat u een hostupgrade voor een “trage site” uitvoert, dient u de drie langzaamste verzoeken van de afgelopen zeven dagen aan te vragen. Vaak is een CREATE INDEX van tien minuten honderd euro VPS waard. Zie Pool-verbindingen en EXPLAIN PostgreSQL voor het Postgres-equivalent.
Beslis en ga vooruit zonder blinde vlek
Maak langzaam inloggen in de productie mogelijk met een drempel van één seconde en verzamel een week aan gegevens voordat er een hardwarebeslissing wordt genomen. Voer EXPLAIN uit op de vijf kritieke routequery's: afrekenen, zoeken, admin. Maak een samengestelde index, meet voor en na op realistische belasting. Plan een driemaandelijkse evaluatie na grote gegevensimporten. Configureer een waarschuwing op rows_examined via APM om drift vóór de volgende handelspiek te detecteren.
Veelgestelde vragen
Hoe herken ik een ontbrekende index?
Activeer het langzame querylogboek en sorteer op onderzochte regels. EXPLAIN geeft type ALL weer of een niet erg selectieve index - hoge zoektijd met rows_examined veel hoger dan rows_sent.
Moeten alle WHERE-kolommen worden geïndexeerd?
Nee. Maak samengestelde indexen in volgorde van de meest selectieve filters. Te veel indexen vertragen INSERT en UPDATE.
Kan een index nutteloos worden?
Ja: tabelgroei, wijziging van zoekopdracht of redundante index via linkervoorvoegsel. Herzien na een grote import- of zoekherontwerp.
Is het vergroten van het RAM-geheugen voldoende?
Tijdelijk. Een volledige scan groeit met de gegevens mee; de bufferpool verbergt de scan één keer, niet de structurele oorzaak.
De site faalt niet zonder reden; hij komt vaak een vraag tegen die EXPLAIN in één regel kan bevestigen.