Prestazioni della versione di MySQL: effetti su velocità e scalabilità

Prestazioni della versione di MySQL è misurabile in termini di tempi di risposta, throughput delle query e scalabilità sotto carico. In questo articolo, utilizzerò dei benchmark reali per mostrare le prestazioni di MySQL 5.7, 8.0, 8.4, 9.1 e 9.2 sotto carico. Velocità e scalabilità e quali interventi di messa a punto sono utili.

Punti centrali

• Versione select: 8.0+ è significativamente migliore con un'elevata concorrenza.
• QPS-Guadagni: fino a +50% contro 5,7 con l'aumento del numero di fili.
• 8.4/9.xottimizzazioni mirate per le scritture e le JOIN.
• SintonizzazioneImpostare correttamente i parametri di pool di buffer, thread, ordinamento e registro.
• TestConvalidare il proprio sysbench sull'hardware di destinazione.

Nozioni di base sulle prestazioni di MySQL

Mi concentro sugli argomenti fondamentali che rendono MySQL veloce: Domande, indici, memoria e IO. InnoDB trae grandi vantaggi da una buona gestione dei buffer, da una progettazione pulita dello schema e da strategie accurate per gli indici. Le versioni moderne riducono l'overhead dello scheduler e migliorano le operazioni di binlog, riducendo i tempi di attesa. Misuro effetti misurabili soprattutto con i piani JOIN, le scansioni degli indici e il controllo dei thread. Se volete le prestazioni, date la priorità a Schema e la configurazione prima degli aggiornamenti hardware.

MySQL 5.7 vs. 8.0: scalabilità e QPS

In condizioni di basso parallelismo, 5.7 offre prestazioni solide, ma con l'aumentare dei thread, il Scala 8.0 è in grado di sopportare una maggiore concurrency e spesso aumenta il QPS per i carichi di lavoro OLTP di 30-50% rispetto a 5.7. Gli indici discendenti evitano il filesort e accelerano notevolmente le letture. L'incremento maggiore si registra nelle operazioni di riga InnoDB e nelle transazioni miste di lettura/scrittura. Tuttavia, un maggiore throughput costa un po' di più CPU, che di solito rimane accettabile sull'hardware attuale.

8.0 Enterprise vs Community: cosa mostrano i benchmark

Nelle misurazioni di Sysbench, 8.0.35 Enterprise raggiunge spesso valori superiori di 21-34%. QPS rispetto all'edizione comunitaria. Il vantaggio deriva dall'ottimizzazione delle strutture interne e da una migliore gestione dei thread. Le prime versioni di 8.0 mostravano occasionalmente regressioni con DELETE/UPDATE, che le patch successive hanno eliminato. Per questo motivo tengo conto dei livelli delle patch e verifico in modo specifico le query critiche. Se si scala in modo prevedibile, si calcola il valore aggiunto a fronte di una maggiore CPU-decisioni sul carico e sull'edizione.

I progressi di 8.4 e 9.x in sintesi

Con 8.4.3 e 9.1.0, le modifiche al tracciamento delle dipendenze binlog aumentano significativamente i carichi di lavoro in scrittura, circa +19,4% per gli aggiornamenti. Le ottimizzazioni delle JOIN (+2,17%) e le migliori scansioni degli indici (+2,12%) aggiungono guadagni incrementali. Su molti carichi di lavoro, vedo circa +7.25% per le scritture e +1.39% per le letture. 9.1.0 è solo minimamente (≈0,68%) indietro rispetto a 8.4.3, ma si sta avvicinando a 8.0.40. In scenari simili a quelli di TPC-C, 9.2 è spesso considerato come il Scalabile e costante, soprattutto oltre i 128 fili.

Versione	Vantaggio principale	Guadagno tipico	Osservazione
5.7	Basso Concorrenza	-	Facile da usare, si bilancia meno bene sotto carico elevato.
8.0	In discesa Indici, fili migliori	+30-50% QPS contro 5,7	Maggiore utilizzo della CPU, chiari vantaggi con l'OLTP.
8.4.3	Dipendenza ottimizzata dal binlog	Scritture +7.25%	Ulteriori vantaggi con le scansioni JOIN e range.
9.1.0	Sintonizzazione fine su Ottimizzatore e la registrazione	≈-0,68% vs. 8.4.3	Vicino a 8.4.3; risultati coerenti.
9.2	Numeri di filettatura elevati	Top con >128 fili	Molto buono Scala nel funzionamento ad alto carico.

Uso questa tabella come aiuto per le decisioni: prima il carico di lavoro, poi la versione, poi la messa a punto. Chi lavora in scrittura sentirà maggiormente la 8.4/9.x. Le applicazioni a prevalenza di lettura traggono già notevoli benefici dalla versione 8.0. Per una crescita costante, la 9.2 rimane una scommessa sicura. Ciò che rimane importante è un sistema pulito strategia di misurazione per hardware di destinazione.

Leggere e utilizzare correttamente i benchmark OLTP

Non valuto i benchmark in modo isolato, ma nel contesto dei miei obiettivi di latenza e throughput. Le operazioni di sola lettura, selezione dei punti e lettura-scrittura si comportano in modo diverso e richiedono analisi differenziate. Interpretazione. I picchi QPS sono convincenti solo se i 95°/99° percentili rimangono stabili. I carichi di produzione spesso combinano brevi SELECT con fasi UPDATE/INSERT intensive. Per le fasi iniziali di ottimizzazione, consultare il documento compatto Suggerimenti per la messa a punto, prima di scavare più a fondo.

Messa a punto: configurazione con effetto

Ho impostato il Pool di buffer di solito a circa 70% della RAM disponibile, in modo che i dati caldi rimangano in memoria. parallel_query_threads lo uso in modo controllato, perché un eccessivo parallelismo è allettante, ma limita le dipendenze. sort_buffer_size lo aumento secondo le necessità ed evito le esagerazioni globali. Le impostazioni di Binlog e le strategie di flush influenzano la latenza e il Produttività apprezzabile. Misuro ogni modifica prima di continuare a girare, in modo da garantire la riproducibilità. Effetti.

Leve di configurazione spesso trascurate

• Ripetere/annullare: innodb_log_file_size e innodb_redo_log_capacity in modo che i checkpoint non vengano premuti troppo frequentemente senza superare il tempo di ripristino. Per le fasi di scrittura, calcolo con >4-8 GB di redo come punto di partenza e convalido con misurazioni del livello di redo.
• A filo/IO: innodb_flush_neighbors disabilitato sulle moderne unità SSD/NVMe, innodb_io_capacity(_max) a IOPS reali, in modo che il lavaggio LRU non avvenga a ondate.
• Change Buffer: per molte scritture di indici secondari, il buffer Cambiare il buffer verificare con il monitoraggio se effettivamente allevia o sposta la pressione.
• Tabelle Tmp: tmp_table_size e max_heap_table_size in modo che le ordinazioni piccole e frequenti rimangano nella RAM; ottimizzare le ordinazioni grandi e rare piuttosto che gonfiarle globalmente.
• Unisci/ordina: join_buffer_size e ordinamento_buffer_size solo moderatamente perché sono allocati per thread. Ottimizzo prima gli indici/piani e per ultimo i buffer.
• Durata: sync_binlog, innodb_flush_log_at_trx_commit e binlog_group_commit consapevolmente: 1/1 è il massimo della sicurezza, valori più alti riducono la latenza con un rischio calcolabile.

Motori di storage e modelli di carico di lavoro

Lo standard è InnoDB, ma i carichi di lavoro sono molto diversi. Verifico se gli indici secondari, i vincoli FK e le funzionalità ACID sono compatibili con il carico di lavoro attuale. Caso d'uso supporto. L'archiviazione dei vecchi dati riduce il carico sulle tabelle primarie e mantiene piccoli i set di lavoro. Per le conoscenze di base sui motori, una panoramica compatta, come ad esempio InnoDB vs. MyISAM. Alla fine, ciò che conta è che il motore, gli indici e le query formino un insieme coerente. Profilo risultato.

Pianificare percorsi di aggiornamento senza rischi

Eseguo l'aggiornamento a tappe: 5.7 → 8.0 → 8.4/9.x, affiancato da controlli di regressione. Prima del cambiamento, congelo le modifiche allo schema e creo dei controlli ripetibili. Test. Poi confronto i piani di query, i percentili e i blocchi. Le strategie blue-green o il failover read-replica riducono i tempi di inattività. Coloro che pianificano correttamente trarranno rapidamente vantaggio dai nuovi Caratteristiche e una maggiore efficienza.

Metodologia di monitoraggio e test

Misuro con Sysbench, integrando le metriche con Performance Schema e strumenti come Percona Toolkit. Più decisivi di un valore medio alto sono il 95°/99° percentile e il varianza. Le analisi del Query Digest scoprono gli schemi costosi prima che scalino in modo costoso. I replay dei carichi di produzione reali forniscono informazioni migliori rispetto ai soli test sintetici. Senza una continua Monitoraggio aggiornamenti rimangono ciechi.

MariaDB vs. MySQL: la scelta pragmatica

MariaDB 11.4 si distingue in alcuni scenari INSERT con un vantaggio di 13-36% rispetto a MySQL 8.0. MySQL 8.0 brilla in OLTP e con un elevato numero di thread, mentre 9.2 è il più forte in >128 thread. Scala spettacoli. Decido in base al carico di lavoro: carico di scrittura con molte piccole transazioni o carico OLTP misto con numerose letture. Entrambi i sistemi offrono risultati affidabili se la configurazione e lo schema sono corretti. La scelta rimane una questione di Carico di lavoro, competenze del team e la roadmap.

Stabilità del piano, statistiche e trucchi per gli indici

Un aggiornamento raramente porta solo più produttività, ma anche nuove euristiche dell'ottimizzatore. Assicuro la stabilità del piano controllando consapevolmente le analisi e le statistiche. Statistiche persistenti e regolare ANALIZZA TABELLA Le corse mantengono le cardinalità realistiche. Quando le distribuzioni dei dati sono fortemente skewed, le Istogrammi (in 8.0+) spesso più delle estensioni generali degli indici. Per le query sensibili, ho impostato specificamente Suggerimenti per l'ottimizzatore, ma con parsimonia, in modo che le versioni future possano continuare a ottimizzare liberamente.

Indici invisibili Lo utilizzo per verificare l'effetto delle rimozioni degli indici senza rischi. Indici funzionali e Colonne generate accelerare i filtri frequenti sulle espressioni o sui campi JSON ed evitare costose fileort/tmp-modifica del percorso. Mantengo le chiavi primarie monotone (AUTO_INCREMENT o varianti UUID basate sul tempo) in modo che le suddivisioni delle pagine e le scritture degli indici secondari non sfuggano di mano. Se si proviene da UUID casuali, misurare l'effetto di una modifica sulla località degli inserti e A filo-Ultimo.

Replicazione e failover con particolare attenzione alle prestazioni

Per una velocità di scrittura elevata, scelgo FILO-con raggruppamenti significativi (impegno di gruppo) e misurare il compromesso tra sync_binlog=1 e 0/100. in scala sulle repliche lavoratori_paralleli_schiavi (risp. operatori_di_replica_parallela) con 8.0+ significativamente migliore, se Tracciamento delle dipendenze funziona correttamente. Negli scenari di failover, la semi-sincronizzazione accelera l'RTO, ma può aumentare la latenza; la attivo selettivamente sui percorsi critici.

Presto attenzione ai dettagli: binlog_checksum e la compressione costano alla CPU, ma fanno risparmiare IO; binlog_expire_logs_seconds impedisce la crescita del registro. Sulle repliche mantengo solo lettura rigorosamente al fine di evitare divergenze, e testare Replica ritardata come protezione contro gli aggiornamenti di massa errati. Per i picchi di carico, è utile allentare temporaneamente i parametri di flush del binlog, purché gli SLO e gli RTO lo consentano.

Gestione delle connessioni e dei thread

Molti colli di bottiglia non si verificano nell'immagazzinamento, ma nella Gestione delle connessioni. Tengo max_connessioni realistico (non massimo), aumentare dimensione_cache_filetto e affidarsi soprattutto a Pool di connessioni dell'applicazione. Scalare le connessioni brevi e frequenti tramite pooling, non tramite il numero di connessioni nude. wait_timeout e timeout_interattivo Li limito a evitare i cadaveri e a osservare la Threads_running vs. Fili_collegati.

Con un parallelismo elevato, l'acceleratore è selettivo: innodb_thread_concurrency Di solito lascio 0 (auto), ma intervengo se i carichi di lavoro cambiano eccessivamente contesto. tabella_aperta_cache e tabella_definizione_cache in modo che gli schemi caldi non vengano costantemente riaperti. In 8.0+ lo scheduler beneficia di migliori mutex; tuttavia impedisco che mandrie tonanti, utilizzando il backoff dell'applicazione e il retry esponenziale al posto degli hard loop.

Realtà hardware, OS e container

MySQL utilizza l'hardware moderno solo se le basi sono adeguate. Sulle macchine NUMA, applico la RAM (interleaved) o lego il processo a pochi nodi per evitare le latenze tra i nodi. Pagine trasparenti di grandi dimensioni Disattivo anche lo swapping; lo scheduler IO è impostato su nessuno (NVMe) o. mq-scadenza. Fisserò la scalatura della CPU al regolatore delle prestazioni in modo che i picchi di latenza non derivino dalle variazioni di frequenza.

A livello di file system, faccio attenzione all'allineamento pulito e alle opzioni di montaggio, e separo binlog, redo e dati se sono disponibili più NVMe. Nei container, imposto le risorse (set di CPU, limiti di memoria) e verifico il comportamento di Fsync del livello di storage. Il throttling del Cgroup spiega altrimenti i presunti „bug del DB“. Chiunque virtualizzi controlla il controllo degli interrupt, la cache di scrittura e il controller a batteria - e verifica che O_DIRETTO viene effettivamente attraversato.

Modello di dati, set di caratteri ed efficienza di memorizzazione

Quando si esegue l'aggiornamento a 8.0+ utf8mb4 Standard - buono per la compatibilità, ma gli indici e le dimensioni delle righe crescono. Controllo più generosamente le lunghezze dei VARCHAR e imposto deliberatamente le collation per controllare i costi di ordinamento. Mantengo i tipi di dati piccoli (p.es. INT invece di PUNTO GRANDE, dove possibile) e utilizzare GENERATO per rendere indicizzabili i filtri calcolati. La compressione è utile per le tabelle molto grandi, se è disponibile il budget per la CPU; altrimenti, ottengo più vantaggi dalla riduzione degli insiemi caldi (archiviazione, partizionamento) che dai livelli di compressione grezzi.

Le chiavi primarie sono una politica di prestazioni: le chiavi monotone agevolano Inserire la località e ridurre le suddivisioni delle pagine; le chiavi casuali aumentano la latenza e l'amplificazione della scrittura. Pulisco regolarmente gli indici secondari - i costi „piacevoli da avere“ sono lineari rispetto ai carichi di scrittura. Valuto lo scopo e la frequenza delle query prima di mantenere gli indici.

Testare in modo sicuro, distribuire in modo sicuro

Strutturo i rilasci in fasi: Traffico ombra contro un'istanza identica 8.0/8.4/9.x, quindi spostamento graduale del traffico (Canary, 5-10-25-50-100%). Confronto i piani di query utilizzando l'analisi digest; in caso di scostamenti, chiarisco se istogrammi, suggerimenti o indici chiudono il percorso di regressione. Punto importante: 8.0 porta una nuova Dizionario dei dati; I salti indietro a 5.7 sono praticamente impossibili: i backup sono quindi obbligatori prima di ogni passaggio definitivo.

Simulo il failover, simulo i tempi di riavvio e il comportamento della replica nella vita reale e controllo la conservazione dei registri per eventuali riavvolgimenti. Rollback Pianifico in modo pragmatico: toggle di configurazione, flag di funzionalità, rollback rapido alle build precedenti, non solo alle versioni del DB. E documento ogni fase di messa a punto con le metriche: senza punti di misurazione, non c'è alcun effetto di apprendimento per l'iterazione successiva.

Sintesi e guida alle decisioni

Posso dire che la versione 8.0 offre grandi incrementi di QPS rispetto alla versione 5.7, mentre le versioni 8.4/9.x spingono ulteriormente le scritture e le JOIN. Chiunque stia pianificando oltre i 128 thread trarrà grandi benefici da 9.2 e da un sistema coerente. Sintonizzazione. I guadagni più rapidi si ottengono con le dimensioni del pool di buffer, gli indici adatti e le impostazioni pulite del binlog. In seguito, ciò che conta è la progettazione delle query, l'analisi della latenza e un percorso di aggiornamento senza sorprese. Con questa tabella di marcia Prestazioni in modo misurabile e affidabile.