my.cnf Optimization: parametri essenziali per migliorare MySQL/MariaDB

Ottimizzare my.cnf non significa “mettere tanti parametri” e sperare in un aumento di velocità. In un server reale, la differenza la fanno pochi valori scelti bene, coerenti con RAM, tipo di carico, dimensione del database e motore usato. Su hosting e VPS la priorità è sempre la stessa: evitare sprechi, ridurre I/O su disco, contenere la memoria e mantenere il servizio stabile anche sotto pressione.

Questa guida si concentra sui parametri davvero utili per MySQL e MariaDB, con un taglio pratico. L’obiettivo non è trasformare il file di configurazione in un elenco infinito, ma costruire una base solida, verificabile e facile da adattare. Quando possibile, conviene procedere per passi: misurare, modificare poco, controllare l’effetto e solo dopo andare oltre.

Prima regola: ottimizzare in base al carico

Non esiste un my.cnf perfetto per tutti. Un server WordPress con traffico medio, un ecommerce con molte scritture e un database applicativo con query pesanti hanno esigenze diverse. Se il server ospita anche web server, PHP-FPM, mail e caching, la memoria disponibile per MySQL/MariaDB si riduce ancora di più.

Prima di cambiare i parametri, conviene guardare almeno questi dati:

• RAM totale e RAM realmente libera nei momenti di picco.
• Numero di connessioni contemporanee e picchi di traffico.
• Presenza di query lente o tabelle molto grandi.
• Tipo di storage: SSD, NVMe o disco tradizionale.
• Versione: MySQL 5.7/8.0 o MariaDB 10.x.

La regola pratica è semplice: se il server ha poca RAM, la priorità è ridurre il consumo; se ha molto I/O su disco, bisogna lavorare sulla cache e sugli indici; se le query sono lente, bisogna intervenire anche sulle tabelle e non solo sulla configurazione.

Backup e verifica prima di toccare my.cnf

Prima di ogni modifica, salva una copia del file di configurazione e controlla dove si trova davvero il file attivo. Su sistemi Linux la posizione può cambiare in base alla distribuzione e al pacchetto installato.

Posizioni comuni:

• /etc/my.cnf
• /etc/mysql/my.cnf
• /etc/mysql/mariadb.conf.d/50-server.cnf
• /etc/my.cnf.d/server.cnf

Verifica anche il motore in uso con un controllo semplice dal pannello o da shell. Se sei su cPanel, Plesk o un ambiente gestito, è importante capire se il file viene sovrascritto da template o da strumenti del provider.

Un backup minimo è sempre consigliato, perché un parametro errato può impedire l’avvio del servizio. Dopo il backup, applica una modifica alla volta e riavvia solo quando hai verificato la sintassi.

I parametri essenziali da conoscere

1. innodb_buffer_pool_size

È il parametro più importante in quasi tutti i casi moderni, perché InnoDB è il motore più usato. Determina quanta memoria viene dedicata al caching dei dati e degli indici InnoDB. Se è troppo basso, MySQL/MariaDB legge troppo spesso da disco. Se è troppo alto, rischi di togliere memoria al sistema e ai servizi web.

In un server dedicato al database può arrivare anche al 60-70% della RAM. In una VPS con più servizi, spesso è più prudente stare tra il 25% e il 50%, lasciando margine per PHP, web server e sistema operativo.

Valori indicativi:

• 2 GB RAM: spesso 512M-1G, con prudenza.
• 4 GB RAM: spesso 1G-2G.
• 8 GB RAM: spesso 2G-4G.
• 16 GB RAM o più: dipende dal carico, ma la cache può salire in modo significativo.

Non esiste un valore universale: se il server ospita anche molti siti PHP, meglio non esagerare.

2. innodb_log_file_size

Influisce sulla capacità di InnoDB di gestire scritture e checkpoint. Un log troppo piccolo può aumentare il lavoro di flush e peggiorare le prestazioni su carichi con molte scritture. Un valore più grande può aiutare, ma va gestito con attenzione perché in alcuni casi richiede una procedura corretta di riavvio e rigenerazione dei log.

Su installazioni moderne si tende a usare valori moderati e coerenti con il carico. Se il database è molto orientato alle scritture, questo parametro merita attenzione insieme a innodb_buffer_pool_size.

3. innodb_flush_method

Serve per definire come InnoDB interagisce con il filesystem e il buffer cache del sistema operativo. Su molte installazioni Linux, il valore O_DIRECT è spesso una scelta utile perché riduce la doppia cache e aiuta a controllare l’uso della memoria.

Non è una bacchetta magica, ma in ambienti con storage veloce e carico InnoDB può dare benefici reali. Va comunque verificato sul proprio sistema e sulla combinazione di filesystem e storage.

4. innodb_file_per_table

Quasi sempre conviene tenerlo attivo. Ogni tabella InnoDB usa un file separato, migliorando gestione, manutenzione e spesso anche recupero dello spazio. È una scelta pratica soprattutto in hosting, dove convivono molti database e molte tabelle.

In ambienti moderni è normalmente impostato su ON. Se non lo è, vale la pena valutarne l’adozione, tenendo conto delle tabelle già esistenti e della necessità di eventuali operazioni di ottimizzazione successive.

5. max_connections

Definisce quante connessioni simultanee può accettare il server. Un valore troppo alto non migliora le prestazioni: spesso peggiora il consumo di RAM e rende il server più vulnerabile ai picchi. Un valore troppo basso, invece, può generare errori di connessione durante i picchi di traffico.

Su hosting condiviso o VPS piccole conviene impostare un numero realistico, non “alto per sicurezza”. Se il tuo sito usa PHP-FPM, cache e query ben ottimizzate, spesso non servono valori estremi. Il punto è bilanciare connessioni e risorse disponibili.

6. wait_timeout e interactive_timeout

Ridurre le connessioni inattive aiuta a liberare risorse. In ambienti web, molte connessioni restano aperte senza reale utilità. Valori troppo alti possono accumulare sessioni inutili; valori troppo bassi possono disturbare applicazioni che mantengono connessioni più lunghe.

Per molti server web, un timeout moderato è più sensato di valori molto elevati. L’idea è evitare connessioni zombie senza penalizzare l’applicazione.

7. query_cache_type e query_cache_size

Qui serve attenzione: la query cache è un argomento delicato. In MySQL 8 è stata rimossa, mentre in MariaDB può esistere ancora in alcune versioni. Su molti carichi moderni la query cache non porta vantaggi reali e può creare contesa sotto traffico concorrente.

In pratica, se usi MariaDB e hai carichi molto specifici, puoi valutarla con prudenza. Per la maggior parte dei casi moderni, soprattutto con WordPress e siti dinamici, è spesso meglio puntare su cache applicativa, object cache e tuning InnoDB.

8. tmp_table_size e max_heap_table_size

Questi due parametri lavorano insieme e influenzano la dimensione delle tabelle temporanee in memoria. Se sono troppo bassi, il server crea più spesso tabelle temporanee su disco, rallentando le query. Se sono troppo alti, rischi di consumare troppa RAM in caso di molte query simultanee.

La regola utile è mantenerli allineati tra loro e scegliere un valore equilibrato. Su server piccoli non conviene esagerare; su server con query complesse e abbastanza memoria, un aumento ragionato può aiutare.

9. sort_buffer_size e join_buffer_size

Questi buffer possono migliorare alcune operazioni, ma sono anche pericolosi se impostati troppo alti, perché vengono allocati per connessione o per operazione. È un errore comune aumentare questi valori “per accelerare tutto” e ritrovarsi con memoria esaurita.

Meglio partire con valori conservativi. In generale, questi parametri non vanno gonfiati alla cieca: prima si ottimizzano query e indici, poi si valuta un ritocco mirato.

10. key_buffer_size

Questo parametro è rilevante soprattutto per tabelle MyISAM. Se il server usa quasi solo InnoDB, il suo peso è molto minore. In ambienti moderni spesso non è il primo parametro da toccare.

Se hai ancora tabelle MyISAM importanti, allora può avere senso assegnargli una quota ragionata. Altrimenti, meglio non consumare memoria inutilmente.

11. table_open_cache e open_files_limit

Servono a migliorare la gestione delle tabelle aperte e dei file. Con molti database, molte tabelle o molti siti ospitati sullo stesso server, questi parametri possono influire sulla reattività e ridurre colli di bottiglia legati all’apertura ripetuta delle tabelle.

Se aumenti table_open_cache, controlla anche open_files_limit e il limite di file del sistema operativo. Altrimenti il valore impostato nel database può risultare poco utile.

12. slow_query_log

Non è un parametro di velocità in senso stretto, ma è uno degli strumenti più utili per migliorare davvero il database. Attivare il log delle query lente permette di vedere dove si perde tempo, quali query vanno ottimizzate e quali indici mancano.

Se vuoi prestazioni serie, il log lento è spesso più utile di qualunque modifica “magica” al file di configurazione. Senza misurazione, si lavora al buio.

Una base di configurazione sensata

La configurazione corretta dipende dal server, ma una base ragionevole per un VPS Linux con carico web standard può includere questi elementi, da adattare con prudenza:

[mysqld]
innodb_buffer_pool_size = 1G
innodb_file_per_table = 1
innodb_flush_method = O_DIRECT
max_connections = 100
wait_timeout = 60
interactive_timeout = 60
tmp_table_size = 64M
max_heap_table_size = 64M
table_open_cache = 400
slow_query_log = 1
slow_query_log_file = /var/log/mysql-slow.log

Questa non è una ricetta universale. È un punto di partenza ragionato. Su un server da 2 GB, ad esempio, alcuni valori vanno ridotti; su una VPS da 8 o 16 GB, alcuni possono essere aumentati. Il criterio migliore è sempre osservare il comportamento reale dopo la modifica.

Come leggere i risultati senza farsi ingannare

Dopo ogni intervento, non basta vedere che il servizio si avvia. Bisogna controllare se il cambio ha migliorato il problema che si voleva risolvere. Un database può partire correttamente ma essere ancora lento, oppure può diventare più veloce in una zona e più fragile in un’altra.

Le metriche da osservare sono semplici:

• Uso RAM del server e swap.
• Carico CPU nei picchi.
• I/O disco durante query pesanti.
• Numero di connessioni attive.
• Presenza di query lente nel log.
• Tempi di risposta del sito, soprattutto TTFB.

Se il server usa WordPress o CMS simili, controlla anche la cache applicativa e il numero di query per pagina. In molti casi il collo di bottiglia non è solo MySQL, ma il modo in cui il sito interroga il database.

Errori comuni da evitare

Il primo errore è copiare una configurazione trovata online senza adattarla alla macchina. Il secondo è aumentare tutto insieme, senza capire quale parametro stia davvero incidendo. Il terzo è ignorare il fatto che un database più veloce non compensa query pessime o indici assenti.

Un altro errore frequente è alzare troppo i buffer per connessione. Questo può sembrare un miglioramento teorico, ma su un server con molte richieste contemporanee si traduce facilmente in pressione sulla memoria e swap, con un peggioramento netto delle prestazioni.

Infine, non bisogna dimenticare che il tuning del database è parte di un lavoro più ampio: web server, PHP, cache, indici, cron, backup e storage devono restare coerenti tra loro.

Approccio pratico consigliato

Il metodo più sicuro è questo:

1. Misura lo stato attuale con log, monitoraggio e carico reale.
2. Modifica un solo gruppo di parametri alla volta.
3. Riavvia il servizio solo dopo aver fatto backup e controllo sintassi.
4. Verifica tempi di risposta, log e uso risorse per almeno qualche ora.
5. Conserva solo i cambiamenti che producono un vantaggio misurabile.

Questo approccio evita l’errore più comune: confondere un cambiamento con un miglioramento. Un server più stabile e prevedibile vale molto più di una configurazione aggressiva che funziona solo in laboratorio.

Conclusione

Ottimizzare my.cnf significa trovare un equilibrio tra memoria, I/O, numero di connessioni e tipo di carico. I parametri davvero importanti sono pochi: innodb_buffer_pool_size, innodb_flush_method, max_connections, i timeout, i buffer temporanei, la cache delle tabelle e il log delle query lente. Tutto il resto viene dopo.

Se vuoi un server più veloce, parti dalla misura, non dall’istinto. E se devi scegliere dove investire il tempo, spesso la combinazione migliore è questa: buffer InnoDB ben dimensionato, query lente sotto controllo, indici corretti e valori conservativi per i buffer per connessione. È il modo più pulito per migliorare davvero MySQL o MariaDB senza introdurre instabilità.