Motore ottimale per piccole tabelle di ricerca in MySQL
-
26-09-2020 - |
Domanda
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
Soluzione
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 !!!
Altri suggerimenti
- "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 entrambiMEMORY
tabella e il backup persistente.MyISAM
ROW_FORMAT=FIXED
- è una storia da vecchie comari;utilizzoDYNAMIC
EVARCHARs
.- 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
EDATEs
.
Voto per InnoDB senza FK.