(Obs:Det här svaret förtydligar eller inte håller med några av de kommentarer som redan skrivits.)
DELETEs saktas ner på grund av att indexposterna raderas. UPDATEs kan saktas ner -- det beror på om en indexerad kolumn ändras.
SELECTs , UPDATEs och DELETEs , men inte INSERTs , behöver hitta raden/raderna; för detta kan ett index hjälpa mycket.
En INSERT skadas ett extra belopp om det finns en UNIQUE index för att kontrollera.
Sekundära nycklar (i InnoDB), utom för UNIQUE nycklar, uppdateras (vanligtvis på grund av INSERT och DELETE , men möjligen på grund av UPDATE ) på ett "fördröjt" sätt via det som kallas "Change Buffer". Detta skjuter faktiskt upp uppdateringen av indexet, men håller fortfarande indexet fullt användbart.
Inget av detta påverkas av ordningen på kolumnerna i ett index. Men om ett index är större än vad som kan cachelagras i RAM, kommer "cachning" in i spelet, och I/O kan vara inblandad eller inte. Men det är ett annat ämne.
I allmänhet förmånen från ett index för att läsa uppväger långt nedgången för skrivoperationer.