mysql - tipo - MyISAM contro InnoDB




tipo myisam (18)

Sto lavorando a progetti che implicano molte scritture di database, direi ( 70% di inserimenti e 30% di letture ). Questo rapporto includerebbe anche gli aggiornamenti che considero essere una lettura e una scrittura. Le letture possono essere sporche (ad es. Non ho bisogno di informazioni accurate al 100% al momento della lettura).
L'attività in questione eseguirà oltre 1 milione di transazioni di database all'ora.

Ho letto un sacco di cose sul web riguardo alle differenze tra MyISAM e InnoDB, e MyISAM mi sembra la scelta più ovvia per il particolare database / tabelle che userò per questa attività. Da quello che sembra che stia leggendo, InnoDB è buono se sono necessarie transazioni poiché il blocco a livello di riga è supportato.

Qualcuno ha esperienza con questo tipo di carico (o superiore)? MyISAM è la strada da percorrere?


Ho discussed brevemente questa domanda in una tabella in modo da poter concludere se andare con InnoDB o MyISAM .

Ecco una piccola panoramica su quale motore di archiviazione db dovresti usare in quale situazione:

                                                 MyISAM   InnoDB
----------------------------------------------------------------
Required full-text search                        Yes      5.6.4
----------------------------------------------------------------
Require transactions                                      Yes
----------------------------------------------------------------
Frequent select queries                          Yes      
----------------------------------------------------------------
Frequent insert, update, delete                           Yes
----------------------------------------------------------------
Row locking (multi processing on single table)            Yes
----------------------------------------------------------------
Relational base design                                    Yes

Riassumere:

Frequent reading, almost no writing   => MyISAM
Full-text search in MySQL <= 5.5      => MyISAM

In tutte le altre circostanze, InnoDB è solitamente il modo migliore per andare.


Ho lavorato su un sistema ad alto volume usando MySQL e ho provato sia MyISAM che InnoDB.

Ho scoperto che il blocco a livello di tabella in MyISAM ha causato seri problemi di prestazioni per il nostro carico di lavoro che sembra simile al tuo. Sfortunatamente ho anche scoperto che le prestazioni di InnoDB erano anche peggiori di quanto avessi sperato.

Alla fine ho risolto il problema della contesa frammentando i dati in modo tale che gli inserti entrassero in una tabella "calda" e non selezionassero mai la tabella calda.

Ciò consentiva anche le eliminazioni (i dati erano sensibili al fattore tempo e mantenevamo solo X giorni vale la pena) per verificarsi su tabelle "obsolete" che ancora non venivano toccate da query selezionate. InnoDB sembra avere scarse prestazioni sulle eliminazioni di massa, quindi se stai pianificando di eliminare i dati potresti voler strutturarli in modo tale che i vecchi dati si trovino in una tabella non aggiornata che può semplicemente essere eliminata invece di eseguire eliminazioni su di essa.

Ovviamente non ho idea di quale sia la tua applicazione, ma spero che questo ti dia qualche informazione su alcuni dei problemi con MyISAM e InnoDB.


Le persone parlano spesso di prestazioni, letture contro scritture, chiavi esterne, ecc. Ma a mio parere c'è un'altra caratteristica indispensabile per un motore di archiviazione: gli aggiornamenti atomici.

Prova questo:

  1. Emetti un UPDATE sulla tua tabella MyISAM che impiega 5 secondi.
  2. Mentre è in corso l'UPDATE, diciamo 2,5 secondi, premi Ctrl-C per interromperlo.
  3. Osserva gli effetti sul tavolo. Quante righe sono state aggiornate? Quanti non sono stati aggiornati? La tabella è leggibile o è danneggiata quando si preme Ctrl-C?
  4. Prova lo stesso esperimento con UPDATE su una tabella InnoDB, interrompendo la query in corso.
  5. Osserva la tabella InnoDB. Le righe zero sono state aggiornate. InnoDB ti ha assicurato aggiornamenti atomici e, se non è possibile eseguire l'intero aggiornamento, ripristina l'intera modifica. Inoltre, la tabella non è corrotta. Funziona anche se usi killall -9 mysqld per simulare un crash.

Ovviamente le prestazioni sono auspicabili, ma non perdere dati dovrebbe prevalere.


Non sono un esperto di database e non parlo per esperienza. Però:

Le tabelle MyISAM utilizzano il blocco a livello di tabella . In base alle stime del traffico, hai quasi 200 scritture al secondo. Con MyISAM, solo uno di questi potrebbe essere in corso in qualsiasi momento . Devi assicurarti che il tuo hardware possa tenere il passo con queste transazioni per evitare di essere sovraccaricato, ovvero una singola query non può richiedere più di 5ms.

Questo mi suggerisce che avresti bisogno di un motore di archiviazione che supporti il ​​blocco a livello di riga, ovvero InnoDB.

D'altra parte, dovrebbe essere abbastanza semplice scrivere alcuni semplici script per simulare il carico con ciascun motore di archiviazione, quindi confrontare i risultati.


Per un carico con più scritture e letture, trarrai vantaggio da InnoDB. Poiché InnoDB offre il blocco delle righe anziché il blocco delle tabelle, i tuoi SELECT possono essere concomitanti, non solo tra loro ma anche con molti INSERT . Tuttavia, a meno che tu non intenda utilizzare transazioni SQL, imposta il commit commit di InnoDB su 2 ( innodb_flush_log_at_trx_commit ). Questo ti restituisce un sacco di prestazioni grezze che altrimenti perdi quando sposti tabelle da MyISAM a InnoDB.

Inoltre, considera l'aggiunta della replica. Questo ti dà un po 'di ridimensionamento della lettura e dato che hai dichiarato che le tue letture non devono essere aggiornate, puoi lasciare che la replica cada un po' indietro. Basta essere sicuri che possa raggiungere qualsiasi cosa tranne il traffico più pesante o sarà sempre dietro e non raggiungerà mai. Se si va in questo modo, tuttavia, si consiglia vivamente di isolare la lettura dagli slave e la gestione del ritardo di replica sul gestore del database. È molto più semplice se il codice dell'applicazione non lo sa.

Infine, fai attenzione ai diversi carichi della tabella. Non avrai lo stesso rapporto di lettura / scrittura su tutte le tabelle. Alcuni tavoli più piccoli con quasi il 100% di letture potrebbero permettersi di rimanere su MyISAM. Allo stesso modo, se hai alcune tabelle che sono vicine al 100% di scrittura, potresti trarre vantaggio da INSERT DELAYED , ma questo è supportato solo in MyISAM (la clausola DELAYED viene ignorata per una tabella InnoDB).

Ma benchmark per essere sicuro.


Se si utilizza MyISAM, non si effettueranno transazioni all'ora, a meno che non si consideri che ciascuna istruzione DML è una transazione (che in ogni caso non sarà duratura o atomica in caso di arresto anomalo).

Quindi penso che devi usare InnoDB.

300 transazioni al secondo sembrano un bel po '. Se si ha assolutamente bisogno che queste transazioni siano resistenti a un'interruzione dell'alimentazione, assicurarsi che il sottosistema I / O sia in grado di gestire facilmente molte scritture al secondo. Avrai bisogno di almeno un controller RAID con cache con batteria tampone.

Se riesci a ottenere un piccolo successo nel tempo, puoi utilizzare InnoDB con innodb_flush_log_at_trx_commit impostato su 0 o 2 (consulta i documenti per i dettagli), puoi migliorare le prestazioni.

Ci sono un certo numero di patch che possono aumentare la concorrenza di Google e di altri: potrebbero essere interessanti se non si riesce a ottenere prestazioni sufficienti senza di essi.


Un po 'tardi per il gioco ... ma ecco un post abbastanza completo che ho scritto qualche mese fa , descrivendo in dettaglio le principali differenze tra MYISAM e InnoDB. Prendi una tazza (e magari un biscotto) e divertiti.

La principale differenza tra MyISAM e InnoDB riguarda l'integrità e le transazioni referenziali. Ci sono anche altre differenze come il blocco, i rollback e le ricerche full-text.

Integrità referenziale

L'integrità referenziale assicura che le relazioni tra le tabelle rimangano coerenti. In particolare, ciò significa che quando una tabella (ad es. Listings) ha una chiave esterna (ad esempio Product ID) che punta a una tabella diversa (ad esempio Prodotti), quando si verificano aggiornamenti o eliminazioni nella tabella puntata, queste modifiche vengono collegate in cascata al collegamento tavolo. Nel nostro esempio, se un prodotto viene rinominato, anche le chiavi esterne della tabella di collegamento verranno aggiornate; se un prodotto viene eliminato dalla tabella "Prodotti", verranno eliminati anche gli elenchi che puntano alla voce eliminata. Inoltre, qualsiasi nuova voce deve avere quella chiave esterna che punta a una voce valida, esistente.

InnoDB è un DBMS relazionale (RDBMS) e quindi ha integrità referenziale, mentre MyISAM no.

Transazioni e Atomicità

I dati in una tabella vengono gestiti utilizzando istruzioni DML (Data Manipulation Language), come SELECT, INSERT, UPDATE e DELETE. Un gruppo di transazioni due o più istruzioni DML insieme in una singola unità di lavoro, quindi viene applicata l'intera unità o nessuna di esse è.

MyISAM non supporta le transazioni mentre InnoDB lo fa.

Se un'operazione viene interrotta mentre si utilizza una tabella MyISAM, l'operazione viene interrotta immediatamente e le righe (o anche i dati all'interno di ciascuna riga) che sono interessati rimangono interessate, anche se l'operazione non è andata a buon fine.

Se un'operazione viene interrotta mentre si utilizza una tabella InnoDB, poiché utilizza transazioni, che hanno atomicità, qualsiasi transazione che non è andata a finire non avrà effetto, poiché non viene eseguito alcun commit.

Blocco della tabella rispetto al blocco della riga

Quando una query viene eseguita su una tabella MyISAM, l'intera tabella in cui viene eseguita la query verrà bloccata. Ciò significa che le query successive verranno eseguite solo al termine di quella corrente. Se stai leggendo una tabella di grandi dimensioni e / o ci sono frequenti operazioni di lettura e scrittura, questo può significare un enorme arretrato di richieste.

Quando una query viene eseguita su una tabella InnoDB, solo le righe coinvolte sono bloccate, il resto della tabella rimane disponibile per le operazioni CRUD. Ciò significa che le query possono essere eseguite contemporaneamente sulla stessa tabella, a condizione che non utilizzino la stessa riga.

Questa caratteristica di InnoDB è nota come concorrenza. Per quanto grande sia la concorrenza, c'è un grande svantaggio che si applica a un intervallo selezionato di tabelle, in quanto c'è un sovraccarico nel passaggio tra i thread del kernel, e dovresti impostare un limite sui thread del kernel per impedire che il server si fermi .

Transazioni e rollback

Quando esegui un'operazione in MyISAM, le modifiche sono impostate; in InnoDB, è possibile eseguire il rollback di tali modifiche. I comandi più comuni utilizzati per controllare le transazioni sono COMMIT, ROLLBACK e SAVEPOINT. 1. COMMIT: puoi scrivere più operazioni DML, ma le modifiche verranno salvate solo quando viene eseguito un COMMIT 2. ROLLBACK - puoi annullare tutte le operazioni che non sono ancora state ancora eseguite 3. SAVEPOINT - imposta un punto nell'elenco di operazioni alle quali può essere eseguito il rollback di un'operazione ROLLBACK

Affidabilità

MyISAM non offre integrità dei dati: guasti hardware, arresti non puliti e operazioni annullate possono causare la corruzione dei dati. Ciò richiederebbe la riparazione completa o la ricostruzione degli indici e delle tabelle.

InnoDB, d'altra parte, utilizza un registro transazionale, un buffer di doppia scrittura e checksum e convalida automatici per prevenire la corruzione. Prima che InnoDB apporti le modifiche, registra i dati prima delle transazioni in un file tablespace di sistema chiamato ibdata1. In caso di arresto anomalo, InnoDB eseguirà il recupero automatico tramite la riproduzione di tali registri.

Indicizzazione FULLTEXT

InnoDB non supporta l'indicizzazione FULLTEXT fino alla versione 5.6.4 di MySQL. Al momento della stesura di questo post, la versione MySQL di molti provider di hosting condivisi è ancora al di sotto 5.6.4, il che significa che l'indicizzazione FULLTEXT non è supportata per le tabelle InnoDB.

Tuttavia, questo non è un motivo valido per utilizzare MyISAM. È meglio passare a un provider di hosting che supporti versioni aggiornate di MySQL. Non che una tabella MyISAM che utilizza l'indicizzazione FULLTEXT non possa essere convertita in una tabella InnoDB.

Conclusione

In conclusione, InnoDB dovrebbe essere il motore di archiviazione predefinito preferito. Scegli MyISAM o altri tipi di dati quando soddisfano un'esigenza specifica.


La domanda e la maggior parte delle risposte non sono aggiornate .

Sì, è una storia di vecchie mogli che MyISAM è più veloce di InnoDB. notare la data della domanda: 2008; ora è quasi un decennio più tardi. InnoDB ha fatto passi da gigante nelle prestazioni da allora.

Il grafico drammatico è stato per un caso in cui MyISAM vince: COUNT(*) senza una WHEREclausola. Ma è davvero quello che passi il tuo tempo a fare?

Se esegui un test di concorrenza , è molto probabile che InnoDB vinca, anche controMEMORY .

Se si effettuano scritture durante il benchmarking SELECTs, MyISAM, MEMORYè probabile che perderanno a causa del blocco a livello di tabella.

In effetti, Oracle è così sicuro che InnoDB è migliore di aver rimosso MyISAM da 8.0.

La domanda è stata scritta all'inizio del giorno 5.1. Da allora, queste versioni principali erano contrassegnate come "Disponibilità generale":

  • 2010: 5,5 (8 in dicembre)
  • 2013: 5,6 (0,10 in febbraio)
  • 2015: 5,7 (0,9 in ottobre)
  • 2018: 8,0 (0,1 in aprile)

In conclusione: non utilizzare MyISAM


MyISAM

Il MyISAM engineè il motore di default nella maggior parte delle MySQLinstallazioni ed è un derivato del tipo di motore ISAM originale supportato nelle prime versioni del sistema MySQL. Il motore offre la migliore combinazione di prestazioni e funzionalità, sebbene manchi di funzionalità di transazione (utilizza i motori InnoDBo BDB) e utilizza table-level locking.

FlashMAX e FlashMAX Connect: leader della piattaforma Flash Transformation Download Now A meno che non sia necessario effettuare transazioni, esistono pochi database e applicazioni che non possono essere archiviati in modo efficace utilizzando il motore MyISAM. Tuttavia, le applicazioni ad alte prestazioni in cui sono presenti un numero elevato di inserimenti / aggiornamenti di dati rispetto al numero di letture possono causare proboelsm delle prestazioni per il motore MyISAM. È stato originariamente progettato con l'idea che oltre il 90% dell'accesso al database di una tabella MyISAM sarebbe stato letto anziché scritto.

Con il blocco a livello di tabella, un database con un numero elevato di inserimenti o aggiornamenti di righe diventa un collo di bottiglia delle prestazioni mentre la tabella viene bloccata mentre vengono aggiunti i dati. Fortunatamente questa limitazione funziona bene anche all'interno delle restrizioni di un database non di transazione.

MyISAM Summary

Nome -MyISAM

Introdotto -v3.23

Installazione predefinita -Sì

Limitazioni dei dati -Nessuno

Limitazioni dell'indice: 64 indici per tabella (32 pre 4.1.2); Massimo 16 colonne per indice

Supporto per le transazioni -No

Livello di blocco -Tabella

InnoDB

Il InnoDB Engineè fornito da Innobase Oye supporta tutte le funzionalità di database (e non solo) del motore MyISAM e aggiunge anche funzionalità di transazione completo (con il pieno ACID(Atomicità, Consistenza, Isolamento e durevolezza) conformità) e il blocco a livello riga di dati.

La chiave del sistema InnoDB è una struttura di database, cache e indicizzazione in cui sia gli indici che i dati vengono memorizzati nella cache e memorizzati su disco. Ciò consente un recupero molto veloce e funziona anche su set di dati molto grandi. Supportando il blocco a livello di riga, è possibile aggiungere dati a una tabella InnoDB senza che il motore blocchi la tabella con ciascun inserto e questo acceleri sia il recupero che l'archiviazione delle informazioni nel database.

Come con MyISAM, ci sono pochi tipi di dati che non possono essere effettivamente memorizzati in un database InnoDB. In effetti, non ci sono ragioni significative per cui non si dovrebbe sempre usare un database InnoDB. Il sovraccarico di gestione per InnoDBè leggermente più oneroso e ottenere l'ottimizzazione giusta per le dimensioni della memoria e delle cache del disco e dei file di database può essere complessa all'inizio. Tuttavia, significa anche che si ottiene una maggiore flessibilità rispetto a questi valori e, una volta impostati, i vantaggi in termini di prestazioni possono facilmente superare il tempo iniziale trascorso. In alternativa, puoi lasciarlo MySQLgestire automaticamente per te.

Se sei disposto (e in grado) a configurare le impostazioni di InnoDB per il tuo server, ti consiglio di dedicare del tempo a ottimizzare la configurazione del tuo server e quindi utilizzare il motore InnoDB come predefinito.

InnoDB Summary

Nome -InnoDB

Introdotto -v3.23 (solo sorgente), v4.0 (sorgente e binario)

Installazione predefinita -No

Limitazioni dei dati -Nessuno

Limiti dell'indice: nessuno

Supporto per le transazioni -Sì (conforme ACID)

Livello di blocco -Row


Tieni presente che la mia formazione formale e la mia esperienza sono con Oracle, mentre il mio lavoro con MySQL è stato interamente personale e ai miei tempi, quindi se dico cose vere per Oracle ma non sono vere per MySQL, mi scuso. Mentre i due sistemi condividono molto, la teoria / algebra relazionale è la stessa, ei database relazionali sono ancora database relazionali, ci sono ancora molte differenze !!

Mi piace particolarmente (oltre al blocco a livello di riga) che InnoDB sia basato sulle transazioni, il che significa che potresti aggiornare / inserire / creare / modificare / rilasciare / etc diverse volte per una "operazione" della tua applicazione web. Il problema che si pone è che se solo alcune di quelle modifiche / operazioni finiscono per essere impegnate, ma altre no, la maggior parte delle volte (a seconda del design specifico del database) finirà con un database con dati / struttura in conflitto.

Nota: con Oracle, le istruzioni create / alter / drop sono chiamate istruzioni "DDL" (Data Definition) e attivano implicitamente un commit. Le istruzioni Insert / update / delete, chiamate "DML" (Manipolazione dei dati), non vengono eseguite automaticamente, ma solo quando viene eseguito un DDL, commit o exit / quit (o se si imposta la sessione su "auto-commit", o se il tuo cliente si auto-commette). È fondamentale essere consapevoli di ciò quando si lavora con Oracle, ma non sono sicuro di come MySQL gestisca i due tipi di istruzioni. Per questo motivo, voglio chiarire che non sono sicuro di ciò quando si tratta di MySQL; solo con Oracle.

Un esempio di quando i motori basati sulle transazioni eccellono:

Diciamo che io o voi siete su una pagina web per iscrivervi per partecipare ad un evento gratuito, e uno degli scopi principali del sistema è quello di consentire a un massimo di 100 persone di registrarsi, poiché questo è il limite del posto a sedere per l'evento. Una volta raggiunte 100 registrazioni, il sistema disabiliterà ulteriori registrazioni, almeno fino all'annullamento di altre.

In questo caso, potrebbe esserci una tabella per gli ospiti (nome, telefono, email, ecc.) E una seconda tabella che tiene traccia del numero di ospiti che si sono registrati. Abbiamo quindi due operazioni per una "transazione". Supponiamo ora che dopo l'aggiunta delle informazioni guest alla tabella GUESTS, si verifichi una perdita di connessione o un errore con lo stesso impatto. La tabella GUESTS è stata aggiornata (inserita in), ma la connessione è stata persa prima che i "posti disponibili" potessero essere aggiornati.

Ora abbiamo aggiunto un guest alla tabella degli ospiti, ma il numero di posti disponibili non è corretto (ad esempio, il valore è 85 quando in realtà è 84).

Ovviamente ci sono molti modi per gestirlo, come tenere traccia dei posti disponibili con "100 meno il numero di righe nella tabella degli ospiti" o un codice che controlla che le informazioni siano coerenti, ecc. Ma con un database basato sulle transazioni motore come InnoDB, TUTTE le operazioni sono impegnate, o NESSUNO di esse lo sono. Questo può essere utile in molti casi, ma come ho detto, non è l'UNICO modo per essere sicuri, no (un modo carino, comunque, gestito dal database, non dal programmatore / sceneggiatore).

Questo è tutto "basato sulla transazione" significa essenzialmente in questo contesto, a meno che non manchi qualcosa - che l'intera transazione abbia successo come dovrebbe, o che nulla è cambiato, dal momento che apportare solo modifiche parziali potrebbe rendere un piccolo problema di SEVERE del database, forse anche corrompendolo ...

Ma lo dirò ancora una volta, non è l'unico modo per evitare di fare casino. Ma è uno dei metodi che gestisce il motore stesso, lasciandovi codice / script con solo bisogno di preoccuparsi di "la transazione è andata a buon fine o meno, e cosa faccio se non lo faccio (come ad esempio riprova)" invece di manualmente scrivere il codice per controllarlo "manualmente" dall'esterno del database e fare molto più lavoro per tali eventi.

Infine, una nota sul blocco delle tabelle rispetto al blocco delle righe:

NOTA BENE: Potrei sbagliarmi in tutto ciò che segue riguardo a MySQL, e le situazioni ipotetiche / di esempio sono cose da esaminare, ma potrei sbagliarmi su cosa sia esattamente possibile causare corruzione con MySQL. Gli esempi sono comunque molto reali nella programmazione generale, anche se MySQL ha più meccanismi per evitare tali cose ...

Comunque, io sono abbastanza fiducioso in accordo con coloro che hanno sostenuto che il numero di connessioni sono ammessi in un momento non non lavorare intorno a un tavolo bloccato. In realtà, più connessioni sono l'intero punto di bloccare un tavolo !! In modo che altri processi / utenti / app non siano in grado di danneggiare il database apportando modifiche contemporaneamente.

In che modo due o più connessioni che funzionano sulla stessa riga fanno un GIORNO MALE PER TE? Supponiamo che ci siano due processi che vogliono / devono aggiornare lo stesso valore nella stessa riga, diciamo perché la riga è un record di un tour in bus, e ciascuno dei due processi desidera aggiornare contemporaneamente i "riders" o "available_seats" campo come "il valore corrente più 1."

Facciamo questo ipoteticamente, passo dopo passo:

  1. Il processo uno legge il valore corrente, diciamo che è vuoto, quindi '0' finora.
  2. Il processo due legge anche il valore corrente, che è ancora 0.
  3. Elabora una scrittura (corrente + 1) che è 1.
  4. Il processo due dovrebbe essere scritto 2, ma poiché legge il valore corrente prima del processo si scrive il nuovo valore, scrive anche 1 nella tabella.

Non sono sicuro che due connessioni potrebbero mescolarsi in questo modo, sia la lettura prima che la prima scrive ... Ma se no, allora vedrei ancora un problema con:

  1. Il processo uno legge il valore corrente, che è 0.
  2. Elabora una scrittura (corrente + 1), che è 1.
  3. Il processo due legge il valore corrente ora. Ma mentre processa una DID write (update), non ha eseguito il commit dei dati, quindi solo lo stesso processo può leggere il nuovo valore che ha aggiornato, mentre tutti gli altri vedono il valore precedente, fino a quando non c'è un commit.

Inoltre, almeno con i database Oracle, ci sono livelli di isolamento, che non perderò il nostro tempo cercando di parafrasare. Ecco un buon articolo su questo argomento, e ogni livello di isolamento che ha i suoi pro e contro, che andrebbe insieme a quanto importanti motori basati su transazioni possono essere in un database ...

Infine, potrebbero esserci diverse salvaguardie in atto all'interno di MyISAM, anziché le chiavi esterne e l'interazione basata sulle transazioni. Bene, per uno, c'è il fatto che un'intera tabella è bloccata, il che rende meno probabile che siano necessarie transazioni / FK .

E, ahimè, se siete a conoscenza di questi problemi di concorrenza, sì potete giocare meno sicuro e scrivere semplicemente le vostre applicazioni, configurare i vostri sistemi in modo che tali errori non siano possibili (il vostro codice è quindi responsabile, piuttosto che il database stesso). Tuttavia, a mio parere, direi che è sempre meglio usare il maggior numero possibile di salvaguardie, programmare in modo difensivo e essere sempre consapevoli che è impossibile evitare completamente l'errore umano. Succede a tutti, e chiunque affermi di essere immune da esso deve mentire o non ha fatto altro che scrivere un'applicazione / script "Hello World". ;-)

Spero che ALCUNE di ciò sia utile per qualcuno, e anche di più, quindi spero di non essere stato colpevole di supposizioni e di essere un errore umano !! Le mie scuse se sì, ma gli esempi sono buoni a cui pensare, ricercare il rischio di, e così via, anche se non sono potenziali in questo specifico contesto.

Sentiti libero di correggermi, modifica questa "risposta", persino votala. Per favore, prova a migliorare, piuttosto che correggere una mia cattiva assunzione con un'altra. ;-)

Questa è la mia prima risposta, quindi per favore perdona la lunghezza a causa di tutte le dichiarazioni di non responsabilità, ecc ... Non voglio sembrare arrogante quando non ne sono assolutamente certo!


In breve, InnoDB è utile se stai lavorando su qualcosa che necessita di un database affidabile in grado di gestire molte istruzioni INSERT e UPDATE.

e, MyISAM è buono se hai bisogno di un database che per lo più richiede molte istruzioni di lettura (SELECT) piuttosto che scrivere (INSERISCI e AGGIORNAMENTI), considerando il suo inconveniente sulla cosa del blocco del tavolo.

potresti voler controllare;
Pro e contro di InnoDB
Pro e Contro di MyISAM


Ogni applicazione ha il proprio profilo di prestazione per l'utilizzo di un database e con ogni probabilità cambierà nel tempo.

La cosa migliore che puoi fare è testare le tue opzioni. Passare da MyISAM a InnoDB è banale, quindi carica alcuni dati di prova e fai fuoco sul tuo sito e guarda cosa succede.


Se si tratta di inserti al 70% e letture del 30%, è più simile al lato InnoDB.


So che questo non sarà popolare ma ecco qui:

myISAM manca del supporto per gli elementi essenziali del database come le transazioni e l'integrità referenziale che spesso si traducono in applicazioni glitchy / buggy. Non è possibile apprendere i fondamentali del design del database se non sono supportati dal tuo motore di database.

Non usare l'integrità referenziale o le transazioni nel mondo del database è come non usare la programmazione orientata agli oggetti nel mondo del software.

InnoDB esiste ora, usa quello! Persino gli sviluppatori MySQL hanno finalmente concesso di cambiare questo motore predefinito nelle nuove versioni, nonostante myISAM fosse il motore originale che era l'impostazione predefinita in tutti i sistemi legacy.

No, non importa se stai leggendo o scrivendo o quali sono le tue considerazioni sulle prestazioni, usare myISAM può causare una serie di problemi, come quello in cui mi sono imbattuto: stavo eseguendo una sincronizzazione del database e allo stesso tempo qualcun altro accesso a un'applicazione che accede a una tabella impostata su myISAM. A causa della mancanza di supporto delle transazioni e della scarsa affidabilità di questo motore, questo ha fatto crashare l'intero database e ho dovuto riavviare manualmente mysql!

Negli ultimi 15 anni di sviluppo ho utilizzato molti database e motori. myISAM si è schiantato su di me circa una dozzina di volte durante questo periodo, altri database, solo una volta! E quello era un database Microsoft SQL in cui alcuni sviluppatori hanno scritto codice CLR errato (Common Language Runtime - in pratica codice C # che si esegue all'interno del database) a proposito, non era esattamente colpa del motore del database.

Sono d'accordo con le altre risposte che affermano che le applicazioni ad alta disponibilità e alta qualità non dovrebbero usare myISAM perché non funzionerà, non è robusto o abbastanza stabile da risultare in un'esperienza senza frustrazione. Vedi la risposta di Bill Karwin per maggiori dettagli.

PS Devi amarlo quando i fan di myISAM svendono, ma non posso dirti quale parte di questa risposta è sbagliata.


myisam è un NOGO per quel tipo di carico di lavoro (scritture di concorrenza elevate), non ho molta esperienza con innodb (l'ho provato 3 volte e ho trovato in ogni caso che la performance faceva schifo, ma è passato un po 'dall'ultimo test) Non sei obbligato a eseguire mysql, considera la possibilità di provare postgres mentre gestisce le scritte concorrenti MOLTO meglio


Ho capito che anche se Myisam ha contesa di blocco, è ancora più veloce di InnoDb nella maggior parte degli scenari a causa dello schema di acquisizione della serratura rapida che utilizza. Ho provato diverse volte Innodb e ricado sempre a MyIsam per un motivo o per l'altro. Anche InnoDB può essere molto impegnativo per la CPU in enormi carichi di scrittura.


Nella mia esperienza, MyISAM è stata una scelta migliore se non si eseguono CANCELLA, AGGIORNAMENTI, un intero lotto di singoli INSERT, transazioni e indicizzazione di testo completo. A proposito, CHECK TABLE è orribile. Man mano che la tabella invecchia in termini di numero di righe, non si sa quando finirà.






myisam