Motore ottimale per piccole tabelle di ricerca in MySQL

Question

Ho la seguente domanda:Sto progettando un'applicazione web con diverse dozzine di piccole tabelle di ricerca:Queste tabelle di solito contengono tre colonne (ID, Nome, Descrizione) e un paio di righe (per lo più meno di 50, il massimo è circa 450).

Si prevede che queste tabelle di ricerca cambino solo raramente (provengono dallo standard, che cambia una volta ogni diversi anni) e verranno utilizzate solo per:

• opzioni di riempimento nella selezione html
• essere uniti ad altri record nei report

Ci sarà solo SELECT dichiarazioni su questi tavoli il 99% delle volte, ma ce ne saranno parecchie.

Mi chiedo, quale motore di database sarebbe più efficiente da utilizzare?

Ecco le mie considerazioni:

MEMORIA

• professionista:molto veloce
• contro:se il server si blocca, tutti i dati vengono persi e devono essere ricreati
• contro:non supporta le chiavi esterne

MyISAM compresso

• professionista:veloce
• contro:non supporta le chiavi esterne

InnoDB

• professionista:supporto per chiavi esterne

Quello che vorrei chiedere è se ci sarà un vantaggio significativo nell'usare qualcosa di diverso da InnoDB - dal punto di vista delle prestazioni

Grazie, Zbynek

Answer 1

Ho risposto a una domanda simile in ago 2011: Quale DBMS è buono per letture super-veloci e una semplice struttura dei dati?

Dato che stai chiedendo di mysql e quale motore di stoccaggio. Per essere onesti, è difficile da dire perché ci sono rare occasioni in cui Myisam può sovraperformare InnoDB quando si seleziona.

Ecco alcuni dei miei post passati su questa controversia

.
• Sep 20, 2011: Best of Myisam e InnoDb .
• May 03, 2012: che è più veloce, InnoDb o Myisam? < / a>
• Jul 05, 2012: InnoDb vs Myisam con molti indici
• Sep 26, 2012: Scegliere Myisam su InnoDB per questi requisiti di progetto; e opzioni a lungo termine

Potresti chiedere adesso: perché avrei mai favorito Myisam su InnoDB?

Dai un'occhiata a questo diagramma (creato da Vadim Tkachenko, percona cto)

Myisam cache cache gli indici e la tabella avrebbero 2 indici (chiave primaria su ID e un indice di nome). D'altra parte, InnoDB ha troppe parti mobili da ospitare, soprattutto se il pool tampone InnoDB deve caricare e licenziare periodicamente le pagine 16k.

Per essere onesti, dovresti fare un esperimento.

.
• Vai al mio post Cosa sono le principali differenze tra InnoDb e Myisam? . Leggilo attentamente.
• Impostare un server utilizzando Myisam e tutte le tabelle usando ROW_FORMAT=Fixed (consultare il mio post Qual è l'impatto sulle prestazioni dell'utilizzo di char vs varchar su un campo di dimensioni fisse? ) e utilizzare un grande key_buffer_size .
• Impostazione di un altro server utilizzando InnoDb e un grande Innodb_buffer_pool_size .
• Aggiungi i tuoi dati a server e interrogarli come pazzi.

Questo ti darà la migliore valutazione per la scelta del motore di archiviazione per il tuo set di dati.

Dai una prova !!!

Answer 2

• "MyISAM compresso" - che cos'è?Forse "Archivio"?
• La compressione non è necessaria;le tabelle sono troppo piccole e verranno rapidamente memorizzate completamente nella cache.
• FOREIGN KEYS -- Perché?Hai eseguito il debug del codice, vero?Non ci saranno cose penzolanti da controllare.
• MEMORY non è irragionevole, Se scrivi il codice 'ricarica' che viene eseguito ogni volta che si apre il server e tutti gli aggiornamenti alla tabella vengono scritti su entrambi MEMORY tabella e il backup persistente.
• MyISAM ROW_FORMAT=FIXED - è una storia da vecchie comari;utilizzo DYNAMIC E VARCHARs.
• Il "cluster" di InnoDB PRIMARY KEY rende le ricerche un po' più veloci di MyISAM per il tuo scopo.
• Fai Sapere che le tabelle di ricerca stanno causando un notevole rallentamento?Dubito seriamente che lo siano.
• Fare non utilizzare le tabelle di ricerca per valori "continui", come FLOATs E DATEs.

Voto per InnoDB senza FK.