Wanneer indexen schadelijk zijn: schrijven en selectiviteit
Schrijfversterking en waarom een index op een kolom met lage selectiviteit nutteloos is.
Wanneer indexen schadelijk zijn: schrijven en selectiviteit is een gratis Voorbereiding op programmeerinterviews-les op CoddyKit. Dit is les 4 van 4. Je kunt de volledige les hieronder gratis lezen en daarna in de browser praktisch oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is. Deze les maakt deel uit van het leertraject Voorbereiding op programmeerinterviews. Je voortgang wordt gesynchroniseerd op het web en in de CoddyKit-app. De cursus Voorbereiding op programmeerinterviews bevat in totaal 4 lessen.
De vraag achter de vraag
Na drie lessen over waarom indexen helpen, draaien gesprekvoerders de vraag om: 'Waarom zou je niet gewoon elke kolom indexeren?' Een sterke kandidaat legt uit dat indexen echte kosten hebben voor schrijfbewerkingen en voor cache en opslag, en dat de planner sommige indexen nooit zal gebruiken.
Deze les behandelt de twee belangrijkste redenen waarom een index nadelig kan zijn: schrijfversterking en lage selectiviteit.
Elke index vertraagt schrijfbewerkingen
Een index moet synchroon blijven met de tabel. Elke INSERT, elke DELETE en elke UPDATE op een geïndexeerde kolom moet ook de indexstructuur bijwerken. Dit is schrijfversterking: één wijziging van een rij wordt één schrijfbewerking voor de tabel plus één schrijfbewerking per betrokken index.
Een tabel met acht indexen vergt ongeveer negen keer zoveel schrijfwerk als een tabel zonder indexen. Bij schrijfintensieve tabellen of tabellen met een hoge verwerkingssnelheid is dat een aanzienlijke last.
Uitgewerkt voorbeeld: de schrijflast
Stel je een gebeurtenissentabel voor die duizenden rijen per seconde binnenkrijgt. Elke extra index zorgt ervoor dat elke invoeging meer werk vereist: indexpagina's splitsen, bladeren bijwerken en concurreren om cachegeheugen.
Voor een tabel waarin alleen rijen worden toegevoegd en die vooral schrijfwerk uitvoert, is het juiste antwoord vaak weinig of geen indexen naast de primaire sleutel. Zware leesbewerkingen kun je dan beter op een replica of datawarehouse uitvoeren.
-- Each of these indexes adds cost to EVERY insert below
CREATE INDEX ix_events_user ON events (user_id);
CREATE INDEX ix_events_type ON events (event_type);
CREATE INDEX ix_events_ts ON events (created_at);
INSERT INTO events (user_id, event_type, created_at)
VALUES (42, 'click', now()); -- now updates table + 3 indexesWat selectiviteit betekent
Selectiviteit geeft aan hoe goed een kolom rijen van elkaar onderscheidt: het aandeel rijen dat overeenkomt met een gebruikelijke waarde. Hoge selectiviteit betekent weinig rijen per waarde, zoals bij een e-mailadres of UUID. Lage selectiviteit betekent veel rijen per waarde, zoals bij een boolean of een status met drie opties.
Indexen leveren vooral voordeel op bij kolommen met hoge selectiviteit, waarbij een opzoekactie bijna alle rijen uitsluit. Bij kolommen met lage selectiviteit leveren ze vaak geen voordeel op.
Waarom een index met lage selectiviteit nutteloos is
Stel dat is_active voor 90% van de gebruikers waar is. Een opzoekactie via de index zou 90% van de tabel opleveren. Voor zoveel rijen zou de databasemotor elke rij afzonderlijk uit de heap moeten ophalen, wat trager is dan de tabel in één keer sequentieel scannen.
De planner negeert de index dus terecht en voert een sequentiële scan uit. De index veroorzaakt dan alleen extra schrijfwerk en opslagkosten, zonder enig leesvoordeel.
-- 90% of rows match: the planner will likely skip this index
CREATE INDEX ix_users_active ON users (is_active);
SELECT * FROM users WHERE is_active = true;De grove drempelwaarde
Een nuttige vuistregel om te benoemen: wanneer een predicaat overeenkomt met meer dan ongeveer 5 tot 20% van een tabel, is een sequentiële scan meestal sneller dan een indexscan, omdat willekeurige ophalingen uit de heap meer kosten dan pagina's in volgorde achter elkaar lezen.
Het precieze omslagpunt hangt af van de rijgrootte, het cachegebruik en de opslagsnelheid. Daarom gebruikt de planner statistieken en geen vast getal om te beslissen.
Gedeeltelijke indexen als oplossing
Als je alleen de zeldzame waarden van een scheve kolom opvraagt, indexeert een partiële index (Postgres) alleen die rijen: klein, selectief en goedkoop in onderhoud.
Als 1% van de bestellingen pending is en je die voortdurend opvraagt, indexeer je alleen die bestellingen. De index blijft klein en de planner gebruikt hem graag.
-- Index only the rare, frequently-queried rows
CREATE INDEX ix_orders_pending
ON orders (created_at)
WHERE status = 'pending';Verouderde statistieken misleiden de planner
De optimizer bepaalt op basis van kolomstatistieken of hij een index of een scan gebruikt. Als die statistieken verouderd zijn, bijvoorbeeld na een bulklading of een grote update, kan hij de selectiviteit verkeerd inschatten en het verkeerde plan kiezen.
Wanneer iemand tijdens een gesprek zegt 'de index bestaat maar wordt niet gebruikt', bevat een sterk antwoord ook het vernieuwen van de statistieken met ANALYZE, voordat je de index zelf de schuld geeft.
ANALYZE orders; -- refresh planner statisticsAndere manieren waarop indexen nadelig zijn
Maak je antwoord compleet met minder bekende kosten:
- Opslag en cache: indexen nemen schijfruimte in en concurreren om geheugen, waardoor nuttige datapagina's worden verdrongen.
- Overbodige of overlappende indexen: ze worden onderhouden maar nooit gekozen.
- Opblazing: bij zware updates raken B-Trees gefragmenteerd en is
REINDEXnodig. - Verwarring bij de optimizer: te veel vergelijkbare indexen maken het plannen trager en minder voorspelbaar.
Ongebruikte indexen vinden
Om een realistische opschoning te onderbouwen, kun je vermelden dat Postgres het gebruik van indexen bijhoudt. Indexen met idx_scan = 0 komen in aanmerking voor verwijdering: ze kosten schrijfwerk en ruimte zonder ooit voor een leesbewerking te worden gebruikt.
SELECT relname AS table_name, indexrelname AS index_name, idx_scan
FROM pg_stat_user_indexes
WHERE idx_scan = 0
ORDER BY relname;Zo formuleer je het tijdens het sollicitatiegesprek
Een volledige, evenwichtige samenvatting:
'Indexen veroorzaken schrijfversterking: bij elke insert/update/delete worden ze bijgewerkt. Daarnaast leggen ze druk op opslag en cache. Ze leveren alleen voordeel op bij predicaten met hoge selectiviteit; op een kolom waarop de meeste rijen overeenkomen, kiest de planner terecht voor een sequentiële scan, waardoor de index alleen maar extra kosten veroorzaakt. Voor scheve kolommen kies ik een partiële index, houd ik de statistieken actueel met ANALYZE en verwijder ik ongebruikte indexen.'
Snelle controle
Bepaal welke index waarschijnlijk het minst opweegt tegen de kosten.
Samenvatting: wanneer indexen nadelig zijn
Belangrijkste punten:
- Elke index zorgt voor schrijfversterking en brengt extra opslag- en cachekosten met zich mee.
- Indexen helpen bij kolommen met hoge selectiviteit; bij kolommen met lage selectiviteit geeft de planner de voorkeur aan een sequentiële scan.
- Wanneer ongeveer 5 tot 20% van de rijen overeenkomt, wint een scan meestal.
- Gebruik een partiële index voor scheve kolommen die je alleen op de zeldzame waarden opvraagt.
- Houd statistieken actueel met
ANALYZEen verwijder ongebruikte indexen (idx_scan = 0).
Daarmee is de cursus over indexeringsstrategie afgerond: bouw indexen waar ze hun kosten terugverdienen en bewijs dat met het uitvoeringsplan.
Leer Voorbereiding op programmeerinterviews met een AI-tutor — gratis
Schrijf echte code en voer die uit in je browser, krijg direct hulp van een AI-tutor die 24/7 beschikbaar is en ga verder waar je gebleven bent op het web of in de app.
- Cursussen
- 90
- Lessen
- 360
Veelgestelde vragen
Is de les “Wanneer indexen schadelijk zijn: schrijven en selectiviteit” gratis?
Ja — de volledige tekst van “Wanneer indexen schadelijk zijn: schrijven en selectiviteit” kun je hier gratis op het web lezen. Als je interactief wilt oefenen met een ingebouwde code-editor en een AI-begeleider die 24/7 beschikbaar is, en de rest van de cursus Voorbereiding op programmeerinterviews wilt ontgrendelen, kun je upgraden naar CoddyKit PRO. De cursus Voorbereiding op programmeerinterviews bevat in totaal 4 lessen.
Wat leer ik in “Wanneer indexen schadelijk zijn: schrijven en selectiviteit”?
Schrijfversterking en waarom een index op een kolom met lage selectiviteit nutteloos is. Je oefent met Voorbereiding op programmeerinterviews door code rechtstreeks in de browser uit te voeren. Een AI-begeleider die 24/7 beschikbaar is beantwoordt je vragen terwijl je de les doorwerkt.
Heb ik ervaring nodig om met Voorbereiding op programmeerinterviews te beginnen?
Ervaring vooraf is niet nodig. Voorbereiding op programmeerinterviews op CoddyKit is opgebouwd voor beginners tot gevorderden, zodat je hier of bij het begin kunt starten en in je eigen tempo kunt leren. Dit is les 4 van 4.
Hoe lang duurt de les “Wanneer indexen schadelijk zijn: schrijven en selectiviteit”?
De meeste lessen van CoddyKit duren ongeveer 5–10 minuten. Elke les is kort en interactief, zodat je gestaag vooruitgaat en op het web en in de app precies verdergaat waar je was gebleven.
Kan ik code schrijven en uitvoeren in deze les over Voorbereiding op programmeerinterviews?
Ja. Elke les over Voorbereiding op programmeerinterviews bevat een ingebouwde code-editor, zodat je rechtstreeks in je browser echte code kunt schrijven en uitvoeren en direct feedback van AI krijgt — lokale installatie is niet nodig.
Alle lessen in deze cursus
- B-tree-indexen en hun nut
- Kolomvolgorde in samengestelde indexen
- Covering-indexen en index-only scans
- Wanneer indexen schadelijk zijn: schrijven en selectiviteit