Riparare una tabella su MySql

Pochi giorni fa ho iniziato a rilevare un sacco di errori su php-stats relativi all’impossibilità di eseguire tutta una serie di query da diverse tabelle.
Il messaggi che ricevevo erano di questo tipo:

#1016 – Can’t open file: ‘nometabella.MYI’ (errno: 130)

All’inizio mi aspettavo fosse un problema dovuto ad una saturazione dello spazio disponibile per il db, così ne ho riallocato un altro paio di MB, ma non notando miglioramenti dopo due giorni ho iniziato a preoccuparmi. Cercando su Google per il messaggio di errore di cui sopra ho trovato solo un risultato relativo significativo che riportava un problema analogo e che suggeriva di tentare di risolvere il problema lanciando il seguente comando SQL:

REPAIR TABLE nometabella;

Nel mio caso sono riuscito a salvare solo una delle tre tabelle corrotte però e a quel punto ho chiesto un consiglio (e anche dei chiarimenti sull’accaduto) al supporto tecnico di TopHost che mi ha risposto suggerendomi di provare il comando:

REPAIR TABLE nometabella USE_FRM;

In questo caso il REPAIR ha avuto successo e php-stats sembra aver ripreso a funzionare correttamente. In seguito però ho voluto cercare di capire un po’ meglio almeno il significato e le eventuali conseguenze di questi interventi di ripristino e a tal proposito mi sono messo a cercare sul “MySQL 5.0 Reference Manual” che alla voce “REPAIR TABLE Syntax” è piuttosto esaustivo.
Ho quindi potuto capire che:

La causa della corruzione delle tabelle, o più precisamente degli indici, è quasi sempre da imputarsi ad un crash improvviso del DB; c’è da capire quanta percentuale di responsabilità sia a carico del servizio di hosting…
Il comando REPAIR TABLE nometabella; tenta semplicemente di ricostruire il file di indice;
Il comando REPAIR TABLE nometabella USE_FRM; va utilizzato proprio nel caso in cui il file di indice non ci sia più o nel caso in cui abbia l’header corrotto. L’opzione USE_FRM fa si che il file .MYI venga ricreato a partire dal file .FRM, per cui si tratta di un intervento più radicale e pericoloso. Lo stesso reference di MySQL dice: “Use this mode only if you cannot use regular REPAIR modes. The .MYI header contains important table metadata (in particular, current AUTO_INCREMENT value and Delete link) that are lost in REPAIR … USE_FRM. Don’t use USE_FRM if the table is compressed because this information is also stored in the .MYI file.“