Flera index för samma kolumn och fulltextindex för enordskolumner

Finns det någon uppenbar situationsoberoende nackdel med att ha ett par olika index för samma kolumn i MySQL eller att ha ett fulltextindex för en VARCHAR-kolumn som bara innehåller ett ord per rad?

Booleska fulltextsökningar är ju så mycket mer flexibla än sökningar i vanliga standardindex. Samtidigt verkar det som om fulltextsökningar är något långsammare än sökningar i vanliga index, vilket är skälet till att jag vill ha båda.

Är inte det största problemet med för mycket indexerande att det tar längre tid att uppdatera, ta bort och reindexera när datan blir väldigt stort?

Det är isåfall det enda nackdelen, enligt mig.

Det är nog ok i det aktuella sammanhanget, där det i nuläget handlar om ca 40 000 rader som utökas gradvis men i klump. Det vill säga det skrivs inte kontinuerligt till databasen utan till en speglad version varifrån det exporteras nytillkommet eller modifierat material lite då och då.

(Två små nackdelar, som jag betraktade som underförstådda, är att fler index tar mer plats – duh? – och att jag inte kan använda InnoDb.)

Du kan släga spegligen då innodb med fulltext finns ute. Kolla version 5.6, kör det själv

Mitt webbhotell ligger lite efter ...

Jag brukar utgå från en förenklad modell när det gäller index. Vad gör man oftast i tabellen? Läser eller skriver? Skriver man mer än vad man läser, lönar sig inte index i det stora hela. Men på så små tabeller du hade, märker man inte av prestandaförlusten, så där kan man ju göra saker och ting lättarbetat istället för optimerat.

I det här fallet är är det läsning och snabba sökresultat som är det viktigaste. Jag skulle nog till och med säga att det är det som motiverar databasens existens. Skrivandet är bara ett nödvändigt ont för att det ska finnas något att söka på.

Om det skulle vara så att skrivprestandan inte räcker till, kan man skriva till en mellanlagringstabell som saknar index (då går det som snabbast att lagra något) och sedan flytta många rader vid samma tillfälle därifrån till den riktiga tabellen. Batch-inserts eller batch-uppdateringar kostar generellt lite mindre prestanda per rad, men nackdelen är att informationen inte finns tillgänglig på rätt ställe precis efter man har sparat ner det.