MySQL Tuner
MySQL Tuner is a built-in performance advisor for the server's MySQL: it reads the live server, scores its configuration against the machine's actual RAM, CPU and disk, explains every recommendation, and applies changes to my.cnf with a safety net that puts everything back if MySQL will not restart. No mysqltuner.pl, no consultants: the analysis engine is native to the panel.
Databases → MySQL Tunerhttps://YOUR-SERVER-IP:8443/databases/mysql-tuner (ROOT only)The Overview: a score you can argue with
The gauge scores the configuration 0-100 (critical findings cost 20 points, warnings 10, informational notes 3), next to the server's facts: MySQL version, uptime, RAM, current versus peak connections, database count, data size, CPU cores and disk type. Below, each recommendation names the exact variable, its current and recommended value, why, and its impact.
SHOW VARIABLES and SHOW GLOBAL STATUS from the live server and sizes recommendations to the machine: buffer pool at 25% of RAM (a shared-hosting split that leaves room for PHP and the panel, not the dedicated-DB 75% folklore), redo log at a quarter of the buffer pool, connection and cache limits scaled from RAM, and I/O capacity by detected disk type (NVMe, SSD or HDD). Runtime counters drive the honest findings: buffer pool hit rate below 99% (only judged after an hour of uptime, so a fresh restart cannot cry wolf), peak connections near the limit, temp tables spilling to disk, and table cache misses.Configuration: edit with a safety net
The Configuration tab lists 41 variables in six groups (InnoDB, connections, memory, logging, replication, charset), each showing current value, recommendation, severity and a restart badge. Edit values directly, or press Apply Recommended on the Overview to stage every critical and warning fix at once; a banner tracks unsaved changes until you apply or discard. Reset to Defaults restores the panel's factory MySQL configuration.
my.cnf is backed up first, the changes are written, and MySQL is restarted (expect a brief interruption of database connections). If MySQL fails to come back up with the new configuration, the panel automatically restores the backup and restarts again on the old settings, so a bad value cannot leave the database down. Only a whitelisted set of variables can be written at all, and apply/reset/benchmark operations are serialized so they cannot race each other.The tab also hosts the phpMyAdmin upload limit control (32 MB to 10 GB): one number that the panel applies atomically to the panel Nginx, the panel's PHP limits and its settings store, so large SQL imports through phpMyAdmin stop dying at the default ceiling.
Benchmark: measure, don't guess
The Benchmark tab runs a real micro-benchmark against a temporary database: a thousand inserts and two hundred mixed selects, timed individually. You get queries-per-second, average and true P95/max latency, buffer pool hit rate and an error count, with quality thresholds marked. The temporary database is dropped afterwards. Run it before and after applying recommendations and the score difference becomes measurable rather than theoretical; results are kept for the session (the history table clears on reload).
Settings reference: every variable the tuner manages
All 41 variables, what they do, and what the panel recommends. "Recommended" values marked scaled are computed from your server's actual RAM, CPU cores or disk type at analysis time. Applying any change restarts MySQL (with the automatic rollback described above).
InnoDB engine
| Variable | What it does | Panel recommendation |
|---|---|---|
innodb_buffer_pool_size |
The main cache holding table data and indexes in RAM; the single most important MySQL setting. Too small means constant disk reads. | Scaled: 25% of RAM (min 128M, max 16G), sized for shared hosting where PHP and the panel need RAM too |
innodb_buffer_pool_instances |
Splits the buffer pool into independent instances to reduce lock contention under concurrency. | Scaled: 1, 2, 4 or 8 by RAM size |
innodb_redo_log_capacity |
Total redo log space; larger logs absorb write bursts with fewer forced flushes. | Scaled: a quarter of the buffer pool (64M to 2G) |
innodb_log_buffer_size |
RAM buffer for redo data before it hits disk; helps large transactions. | 32M |
innodb_flush_log_at_trx_commit |
The durability/speed dial. 1 flushes every commit (safest, slowest); 2 flushes once per second, risking about one second of transactions on a full OS crash; 0 is fastest and least safe. |
2 (balanced for web hosting) |
innodb_flush_method |
How InnoDB writes to disk. O_DIRECT bypasses the OS page cache, avoiding double-caching the same data. |
O_DIRECT |
innodb_file_per_table |
Each table gets its own tablespace file, so dropping a table actually returns disk space. | ON |
innodb_io_capacity |
Background I/O budget (IOPS) for flushing and merging. Should match what the storage can really do. | Scaled: NVMe 4000, SSD 2000, HDD 200 |
innodb_io_capacity_max |
The burst ceiling for background I/O under pressure. | Scaled: NVMe 8000, SSD 4000, HDD 400 |
innodb_read_io_threads |
Background threads for read I/O. | Scaled: CPU cores, capped at 8 |
innodb_write_io_threads |
Background threads for write I/O. | Scaled: CPU cores, capped at 8 |
innodb_thread_concurrency |
Limit on threads inside InnoDB at once. | 0 (unlimited; modern InnoDB self-regulates) |
innodb_buffer_pool_dump_at_shutdown |
Saves the buffer pool's page list on shutdown. | ON |
innodb_buffer_pool_load_at_startup |
Reloads that list at startup so the cache starts warm instead of cold. | ON |
Connections
| Variable | What it does | Panel recommendation |
|---|---|---|
max_connections |
Maximum simultaneous client connections; each consumes RAM, so bigger is not better. | Scaled: RAM/20 MB, clamped to 50-500 |
max_connect_errors |
How many failed connects from one host before it is blocked. Low values lock out app servers after transient hiccups. | 1000000 |
wait_timeout |
Seconds before an idle non-interactive connection is dropped; frees abandoned PHP connections. | 600 |
interactive_timeout |
The same for interactive clients (CLI sessions). | 600 |
thread_cache_size |
Threads kept for reuse instead of being created per connection. | Scaled: RAM/64 MB, clamped to 16-100 |
back_log |
Queue depth for connections waiting to be accepted during spikes. | 128 |
max_allowed_packet |
Largest single packet/row/BLOB the server accepts; too low breaks big imports. | 64M |
Memory buffers
| Variable | What it does | Panel recommendation |
|---|---|---|
tmp_table_size |
Ceiling for in-memory temporary tables; beyond it they spill to disk (a classic hidden slowdown for GROUP BY/ORDER BY). | Scaled: 2% of RAM (32M-256M) |
max_heap_table_size |
Ceiling for MEMORY-engine tables; effective temp-table limit is the lower of this and the above, so they move together. | Same as tmp_table_size |
table_open_cache |
Open table handles kept cached; hosting servers with many sites touch many tables. | Scaled: RAM×2 per MB, clamped to 1000-10000 |
table_definition_cache |
Cached table definitions (schemas). | 2000 |
sort_buffer_size |
Per-sort, per-connection buffer; large values multiply across connections, so keep modest. | 4M |
read_buffer_size |
Per-connection buffer for sequential table scans. | 2M |
read_rnd_buffer_size |
Per-connection buffer for reading sorted rows back in order. | 2M |
join_buffer_size |
Buffer for joins that lack a usable index; a large value here usually masks a missing index. | 4M |
key_buffer_size |
MyISAM index cache; only legacy tables use it, so it stays small. | 32M |
bulk_insert_buffer_size |
Speeds up bulk MyISAM inserts. | 32M |
Logging
| Variable | What it does | Panel recommendation |
|---|---|---|
slow_query_log |
Records queries slower than the threshold; the first tool for finding what hurts. | ON |
long_query_time |
The slow threshold, in seconds. | 2 |
log_queries_not_using_indexes |
Also log index-less queries; noisy on real workloads. | OFF |
general_log |
Logs every statement; heavy overhead, debug-only. | OFF |
log_error_verbosity |
Error log detail (1 errors, 2 +warnings, 3 +notes). | 2 |
Binary log / replication
| Variable | What it does | Panel recommendation |
|---|---|---|
binlog_expire_logs_seconds |
How long binary logs are kept before purging. | 604800 (7 days) |
max_binlog_size |
Size at which the binlog rotates to a new file. | 256M |
sync_binlog |
How often the binlog is fsynced; 0 lets the OS decide (fastest), 1 syncs every commit (needed for real replication safety). |
0 (the panel's factory config disables the binlog entirely on standalone servers) |
Character set
| Variable | What it does | Panel recommendation |
|---|---|---|
character_set_server |
Default charset for new databases; shown read-only because the panel standardizes on full Unicode. | utf8mb4 |
collation_server |
Default collation (comparison/sorting rules). | utf8mb4_unicode_ci |
Access
Strictly ROOT for viewing and applying (the backend additionally allows ADMIN read access over the API). This is a server-wide tuning tool, not a per-account one, so it lives with the other ROOT-only server tools; see roles and permissions. Analysis is read-only; only Apply and Reset write to the server, both behind explicit confirmation dialogs listing exactly what will change.