Quali opzioni di configurazione per MySQL offrono i maggiori miglioramenti della velocità?

Quali opzioni di configurazione per MySQL offrono i maggiori miglioramenti della velocità?

Mi chiedo quali siano i miglioramenti dei file di configurazione, i tipi di tabella, le impostazioni hardware, la replica, ecc. Nient'altro che la struttura della query e la struttura della tabella (sono facili da trovare sul sito Web e Stack Overflow). Cose come le impostazioni della cache delle query ti hanno dato la massima velocità? Che ne dici di unità; è meglio averlo su un RAID esterno o interno? La replica ti ha dato prestazioni migliori, soprattutto con query di lettura di grandi dimensioni?

Quali altre impostazioni / modifiche hai apportato per migliorare le prestazioni di MySQL?

Nota: mi rendo conto che questi dipendono molto dall'utilizzo (vale a dire un piccolo sito Web rispetto a un data warehouse), ma poiché penso che la maggior parte di noi probabilmente lavori su una varietà di siti / sistemi, è bene conoscere una varietà di tecniche che possono essere applicate a diversi situazioni. Inoltre, penso che alcune tecniche possano essere trasferite tra situazioni.

Ecco i miei consigli (il tuo millage può variare)

• Usa RAID hardware. Ciò è contrario alle mie raccomandazioni di utilizzare il software RAID in altri post, tuttavia questa è una situazione specifica in cui si desidera la scheda RAID hardware. In particolare, si desidera che la NVRAM supportata da batteria sulla scheda RAID riduca il tempo necessario per sincronizzare il file di registro su disco.
• Utilizzare SOLO volumi RAID 1 o RAID 10. Il costo delle scritture RAID 5 o 6 è troppo elevato per tollerare in un carico di lavoro misto di lettura / scrittura.
• Utilizzare LUN separati per i volumi di dati, log e tmp. Questi dovrebbero essere tutti separati dal sistema operativo e dai volumi di scambio.
• Usa InnoDB .
• Usa innodb_file_per_table
• Utilizzare un sistema operativo a 64 bit
• Imposta il pool di buffer InnoDB su ~ 80% della RAM disponibile
• Impostare i file di registro su 1/4 della dimensione del pool di buffer, tra 2 e 4 file di registro. File di registro più grandi significano tempi di arresto e recupero più lenti, ma consentono di ripristinare più rapidamente dump di database di grandi dimensioni.
• log_slow_queries, log-queries-not-using-indexes, set-variabile = long_query_time = 1, investiga ogni query in quel registro, rifattorizza il tuo schema per evitare scansioni di tabelle e tabelle tmp quando possibile.

Ancora una volta Dave Cheney lo ha davvero buttato fuori dal parco qui. Non posso davvero aggiungere nulla alla sua risposta alla tua domanda. Tuttavia, vorrei sottolineare ciò che non hai chiesto. Come Jeremy Zawodny e Peter Zaitsev mi hanno insegnato anni fa, il tuo ROI per il tempo speso a rintracciare e ottimizzare le query errate sta andando fuori per eseguire il tuo ROI per il tempo impiegato a modificare la configurazione 10 volte. Certo, non si desidera avere una configurazione scadente, una configurazione RAID errata o una RAM insufficiente. Ma, tra le eccellenti e persino marginali, le cattive query DBA di MySQL (di solito da sviluppatori / framework, non dal DBA) sono una condizione cronica , in cui una cattiva configurazione è sostenibile .

(Ho scavato per quegli aggettivi per un po 'e ancora non sono contento di quelli che ho scelto.)

Vorrei sottolineare ancora una volta che se i tuoi sviluppatori utilizzano un ORM come quelli comuni in framework come Ruby on Rails e Django, DEVI REALMENTE monitorare le query che colpiscono il tuo DB. Quando gli sviluppatori smettono di pensare a SQL e lasciano che il DB venga sottratto, questo brutto insinuarsi. Adoro i due framework che ho appena citato. (Non votatemi per averli insultati.) Rende solo molto importante l'interrogatorio. (Leggi: Sicurezza del lavoro)

Poche altre cose (che non sono state menzionate nella risposta di Dave Cheney)

• Prova a impostare innodb_flush_method su O_DIRECT per evitare il doppio buffering dei dati. Evitalo se la tua scheda RAID non ha una cache di scrittura supportata da batteria o se i tuoi dati sono su una SAN.

• Gioca anche con innodb_thread_concurrency. Credo che il valore predefinito sia 8, ma vale la pena modificarlo per vedere se migliora le prestazioni

• Assicurati che la cache delle query sia attivata e controlla le statistiche per vedere qual è la percentuale di hit. Se va bene, prova ad aumentarlo per vedere se migliora la frequenza dei colpi.

• A seconda delle applicazioni eseguite, potrebbe essere possibile modificare il livello di isolamento predefinito. L'impostazione predefinita è REPEATABLE_READ ma READ_COMMITTED potrebbe offrire prestazioni migliori

• Se le tue dichiarazioni sono per lo più AGGIORNAMENTI ed ELIMINI, allora potresti provare ad adescare la cache sullo slave eseguendo una query SELECT che restituisce il set di risultati che deve essere modificato. Dai un'occhiata allo strumento mk-slave-prefetch che lo farà per te

• Dai un'occhiata ad altri motori di archiviazione oltre a MyISAM e InnoDB

Non posso dire nulla sull'hardware, ma potresti provare http://blog.mysqltuner.com . È uno script Perl che analizza le impostazioni di MySQL.

Puoi vedere un output di esempio su http://www.thomas-krenn.com/de/wiki/MySQL_Performance_Tuning#mysqltuner.pl

La prima cosa generale che dovresti fare è guardare i parametri di memoria. Le impostazioni predefinite per MySQL sono molto conservative. Qualunque sia il motore che usi, probabilmente dovrai aumentare di dieci o addirittura cento volte il numero dei parametri di memoria.

La prossima cosa che dovresti fare è guardare la cache della tabella. Il valore predefinito è 64, utile solo se non si dispone di più di circa 60 tabelle. Ti consigliamo di aumentare molto.

La terza cosa che dovresti fare è guardare il thread e i parametri di connessione. Wait_timeout predefinito è estremamente lungo per la maggior parte delle applicazioni basate sul Web e può essere ridotto a circa 30 secondi. Ciò migliorerà anche l'utilizzo della memoria, poiché MySQL raccoglierà le connessioni prima, lasciando molto meno in giro in uno stato di "sospensione".