Migliori pratiche di ottimizzazione del database MySQL

Question

Quali sono le migliori pratiche per l'ottimizzazione di un'installazione MySQL per le migliori prestazioni quando si gestiscono tabelle un po 'più grandi (> 50k record con un totale di circa 100 MB per tabella)? Stiamo attualmente valutando la possibilità di riscrivere DelphiFeeds.com (un sito di notizie per la comunità di programmazione Delphi) e abbiamo notato che semplici istruzioni di aggiornamento possono richiedere fino a 50 ms. Questo sembra molto. Ci sono delle impostazioni di configurazione raccomandate che dovremmo abilitare/impostare che sono normalmente disabilitate su un'installazione standard di MySQL (ad esempio per sfruttare più RAM per memorizzare query e dati e così via)?

Inoltre, quali sono le implicazioni di prestazioni della scelta dei motori di archiviazione? Stiamo progettando di utilizzare InnoDB, ma se MyISAM è consigliato per motivi di prestazioni, potremmo utilizzare MyISAM.

Answer 1

Il "best practice" è:

1. Misurare le prestazioni, isolare il sottosistema così come si può.
2. Identificare la causa principale del collo di bottiglia. Sei collegato I/O? CPU vincolata? Legato alla memoria? In attesa di serrature?
3. Apporta le modifiche per alleviare la causa principale che hai scoperto.
4. Misurare nuovamente, per dimostrare che è stato risolto il collo di bottiglia e di quanto.
5. Passare al punto 2 e ripetere se necessario finché il sistema non funziona abbastanza velocemente.

Iscriviti al feed RSS allo http://www.mysqlperformanceblog.com e leggi anche i suoi articoli storici. Questa è una risorsa estremamente utile per la saggezza legata alle prestazioni. Ad esempio, hai chiesto informazioni su InnoDB e MyISAM. La loro conclusione: InnoDB ha prestazioni del ~ 30% in più rispetto al MyISAM in media. Sebbene ci siano anche alcuni scenari di utilizzo in cui MyISAM supera Outno in InBob.

• InnoDB vs. MyISAM vs. Falcon benchmarks - part 1

Gli autori di questo blog sono anche co-autori di "High Performance MySQL", il libro di cui parla @Andrew Barnett.

---

Re commento da @ ʞɔıu: come dire se sei O bound rispetto CPU bound rispetto della memoria legato I/dipende dalla piattaforma. Il sistema operativo può offrire strumenti come ps, iostat, vmstat o top. Oppure potresti dover ottenere uno strumento di terze parti se il tuo sistema operativo non ne fornisce uno.

Fondamentalmente, qualsiasi risorsa è ancorata al 100%, l'utilizzo/saturazione è probabilmente il collo di bottiglia. Se il carico della CPU è basso ma il carico di I/O è al massimo per l'hardware, allora sei vincolato all'I/O.

Questo è solo un punto dati, tuttavia. Il rimedio può dipendere anche da altri fattori. Ad esempio, una query SQL complessa potrebbe eseguire un filesort e ciò mantiene l'I/O occupato. Dovresti gettare hardware più/più veloce, o dovresti riprogettare la query per evitare il filesort?

Ci sono troppi fattori da riepilogare in un post di StackOverflow e il fatto che molti libri esistano sull'argomento lo supporta.Mantenere i database operativi in ​​modo efficiente e utilizzare al meglio le risorse è un lavoro a tempo pieno che richiede competenze specializzate e studio costante.

---

Jeff Atwood ha appena scritto un bel articolo del blog di trovare i colli di bottiglia in un sistema:

• The Computer Performance Shell Game

Answer 2

Acquista "MySQL ad alte prestazioni" da O'Reilly. Sono circa 700 pagine sull'argomento, quindi dubito che troverai una risposta sintetica su SO.

Answer 3

E 'difficile broadbrush cose, ma una visione moderatamente-alto livello è possibile .

• È necessario valutare leggere: rapporti di scrittura. Per le tabelle con rapporti inferiori a circa 5: 1, probabilmente trarrai vantaggio da InnoDB perché gli inserimenti non bloccheranno i selettivi. Ma se non si stanno utilizzando le transazioni, è necessario modificare innodb_flush_log_at_trx_commit su 1 per ottenere prestazioni su MyISAM.
• Controllare i parametri di memoria. Le impostazioni predefinite di MySQL sono molto conservative e alcuni limiti di memoria possono essere aumentati di un fattore 10 o più anche su hardware normale. Questo avvantaggerà i tuoi SELECT piuttosto che INSERT.
• MySQL può registrare cose come query che non utilizzano indici, così come query che richiedono troppo tempo (definibili dall'utente).
• La cache delle query può essere utile, ma è necessario strumentalizzarla (ad esempio, vedere quanto viene utilizzata). Cactus può farlo; come può Munin.
• progettazione delle applicazioni è anche importante:
  • leggermente caching serie di dati spesso recuperati, ma un po 'piccole avranno una grande differenza (cioè durata della cache di pochi secondi).
  • Non recuperare i dati che hai già a disposizione.
  • Lo storage multi-step può aiutare con un volume elevato di inserimenti in tabelle che sono anche leggibili. L'idea di base è che puoi avere una tabella per inserimenti ad-hoc (può anche essere utile il INSERT DELAYED), ma un processo batch per spostare gli aggiornamenti all'interno di MySQL da lì a dove stanno accadendo tutte le letture. Ci sono variazioni di questo.
• Non dimenticate che la prospettiva e il contesto sono importanti, troppo: quello che si potrebbe pensare è un tempo lungo per un UPDATE accada potrebbe in realtà essere abbastanza banale se questo aggiornamento "lungo" capita solo una volta al giorno.

Answer 4

Ci sono tonnellate di best practice che sono state precedentemente discusse quindi non c'è motivo di ripeterle. Per consigli effettivamente concreti su cosa fare, proverei a correre MySQL Tuner. È uno script perl che puoi scaricare e poi eseguire sul tuo server di database, ti darà un po 'di statistiche su come il tuo database sta funzionando (es. Colpi di cache) insieme ad alcune raccomandazioni concrete su quali problemi o parametri di configurazione devono essere aggiustati per migliorare le prestazioni.

Mentre queste statistiche sono tutte disponibili in MySQL stesso, trovo che questo strumento le offra in modo molto più facile da capire. Mentre è importante notare che YMMV rispetto alle raccomandazioni, ho trovato che generalmente sono abbastanza accurate. Assicurati di aver fatto un buon lavoro esercitando il database in anticipo con un traffico realistico.