(Bemærk:Dette svar præciserer eller er uenigt med nogle af de kommentarer, der allerede er skrevet.)
DELETEs bliver langsommere på grund af sletning af indeksposterne. UPDATEs kan blive langsommere -- det afhænger af, om en indekseret kolonne ændres.
SELECTs , UPDATEs og DELETEs , men ikke INSERTs , skal finde rækken/rækkerne; til dette kan et indeks hjælpe meget.
En INSERT er skadet et ekstra beløb, hvis der er en UNIQUE indeks for at kontrollere.
Sekundære nøgler (i InnoDB), undtagen for UNIQUE nøgler, opdateres (normalt på grund af INSERT). og DELETE , men muligvis på grund af UPDATE ) på en 'forsinket' måde via det, der kaldes "Change Buffer". Dette udsætter faktisk opdatering af indekset, men holder stadig indekset fuldt brugbart.
Intet af dette påvirkes af rækkefølgen af kolonnerne i et indeks. Men hvis et indeks er større, end det kan cache i RAM, kommer "caching" i spil, og I/O kan være involveret eller ikke. Men det er et andet emne.
Generelt fordele fra et indeks for læsning opvejer langt afmatningen for skriveoperationer.