Sono pronto per passare da MyISAM a InnoDB ma volevo sapere se c'era un elenco completo di cose da cercare? Ad esempio, non ho visto alcun elenco menzionare che l'esecuzione DISABLE KEYSsu una tabella InnoDB genererà un avviso, ad eccezione della pagina di manuale per ALTER TABLE. È quel genere di cose che devo sapere prima di convertirmi. Ho pensato di stare bene con le mie domande ma apparentemente no.

Ecco alcuni gotchas

Utilizzo della memoria

MyISAM

• memorizza solo le pagine dell'indice nella cache.
• keycache condivisa (dimensionato da key_buffer_size).
• Puoi anche impostare un keycache dedicato, una o più tabelle per tabella cache .

InnoDB

• memorizza nella cache le pagine dei dati e le pagine dell'indice.
• un pool di buffer e una dimensione prima di MySQL 5.5
• 1 o più pool di buffer che iniziano con MySQL 5.5

Ecco alcune domande che ho scritto e pubblicato in precedenza su come scegliere una dimensione corretta per MyISAM Key Cache e InnoDB Buffer Pool .

Indici FULLTEXT

MyISAM

• Supporta indici FULLTEXT

InnoDB

• A partire da MySQL 5.6, sì, ma ancora in versione beta (AGGIORNAMENTO: MySQL 5.6 esiste e ha indici FULLTEXT. Se si utilizza l'indicizzazione FULLTEXT in MySQL 5.6, assicurarsi di utilizzare le opzioni FULLTEXT specifiche di InnoDB )
• Prima di MySQL 5.6, ciò significa che non è possibile convertire MyISAM in InnoDB.

MySQL 5.5 e versioni successive

Per individuare quali tabelle MyISAM hanno un indice FULLTEXT eseguire questa query:

select tbl.table_schema,tbl.table_name from
(
    select table_schema,table_name
    from information_schema.tables
    where engine='MyISAM'
    and table_schema NOT IN ('information_schema','mysql')
) tbl
INNER JOIN
(
    select table_schema,table_name
    from information_schema.statistics
    where index_type='FULLTEXT'
) ndx
USING (table_schema,table_name);

Qualunque cosa provenga da questa query non può essere convertita in InnoDB fino a quando non si aggiorna a MySQL 5.6.

OTTIMIZZA TABELLA

MyISAM

• La tabella MyISAM è ridotta
• TABELLA ANALISI esegue le statistiche degli indici su tutti gli indici

InnoDB

• ANALYZE TABLE è totalmente inutile perché le statistiche dell'indice vengono sempre ricordate
• Con innodb_file_per_table disabilitato, ibdata1 diventerà più grande
• Con innodb_file_per_table abilitato, il file tablespace (.ibd) viene ridotto

Penso che il più grande gotcha sarebbe innodb essendo transazionale. Ti consigliamo di sapere se le librerie MySQL utilizzate dalle tue applicazioni auto_commit per impostazione predefinita o meno.

Python , ad esempio, non esegue il commit automatico. Ciò significa che se un'applicazione stava inserendo una riga subito prima della chiusura della sua connessione, l'inserzione verrebbe ora ripristinata dopo la modifica a innodb. Lo script python per esempio dovrebbe essere sicuro di chiamare connection.commit ();

Un altro punto di differenza potrebbe riguardare inserimenti o aggiornamenti su più righe. Prendi in considerazione un inserto a più righe

insert into tbl values (...row1...),  (...row2...),  (...rowN....);

Considera cosa succede se c'è un qualche tipo di errore come una collisione di chiavi univoca su row3. Con MyISAM le prime due righe sarebbero state scritte, sotto innodb tutte le righe che venivano scritte sarebbero state ritirate senza lasciare nulla di scritto al pari di tale errore.

Con innodb entrerai nel mondo dei deadlock. Questi non sono intrinsecamente cattivi a meno che non si verifichino con tale frequenza per impedire qualsiasi lavoro da svolgere. Tuttavia, le applicazioni dovranno essere codificate in modo tale da anticipare deadlock e gestirle in modo appropriato (il che molto probabilmente significa semplicemente riprovare).

Considerare le limitazioni di memoria / archiviazione. Innodb richiede molte più risorse rispetto a MyISAM. Se hai abbastanza RAM per mantenere i tuoi pool di buffer abbastanza grandi da contenere tutti i tuoi tavoli, allora sei d'oro.

Cerca tabelle con chiavi primarie di grandi dimensioni. L'indicizzazione in cluster di Innodb indica che ogni indice secondario contiene un'altra copia del PK della riga corrispondente. Se hai 2 indici secondari significa che ogni riga PK viene memorizzata 3 volte (PK + ogni indice). Se il pk si estende su più colonne e tipi di dati di grandi dimensioni (ad esempio char (N)), puoi vedere come i requisiti dell'indice possono esplodere rapidamente in innodb.