How to use MySQLTuner for MySQL or MariaDB

Running a tuning assessment tool highlights common configuration problems that waste RAM, increase disk I/O, or create avoidable contention under load.

MySQLTuner connects to a running MySQL or MariaDB server, reads server variables plus global status counters, and compares observed behavior to practical heuristics. The report typically calls out hotspots around caches, connection handling, temporary tables, and storage engine efficiency.

Recommendations are workload-sensitive and strongly influenced by uptime, traffic mix, and server role. Run the tool during representative load, treat suggestions as hypotheses to validate, and apply changes incrementally with before/after measurements to avoid “fixing” one bottleneck by creating another.

1. Run mysqltuner to capture a baseline report.

   $ mysqltuner
    >>  MySQLTuner 2.2.1
    >>  Important MySQL Timers
        Uptime:             2 days 04 hours 00 min 12 sec
    >>  Scanned log files:  /var/log/mysql/mysql-slow.log
   ##### snipped #####
   Please enter your MySQL administrative login: root
   Please enter your MySQL administrative password:
   ##### snipped #####

   Package and binary names vary; the command is commonly mysqltuner or mysqltuner.pl depending on packaging.

2. Scan key sections such as throughput, slow query, cache, InnoDB to identify the biggest constraints.

   -------- Performance Metrics -------------------------------------------------
   [--] Queries per second: 612.4 (Reads/Writes: 92%/8%)
   [--] Slow queries: 0% (14/12789432)
   [OK] Query cache is disabled
   [OK] InnoDB buffer pool / data size: 8.0G/10.2G
   ##### snipped #####

3. Focus first on lines marked [!!] to prioritize actionable warnings.

   -------- Recommendations -----------------------------------------------------
   General recommendations:
       [!!] Reduce your overall MySQL memory footprint for system stability
   ##### snipped #####

   MySQLTuner output is heuristic-driven; a warning indicates a likely pressure point, not an automatic “set X to Y” instruction.

4. Treat memory-related recommendations as a budget exercise before applying them.

   Increasing innodb_buffer_pool_size, tmp_table_size, or max_connections without headroom can push the host into swapping, which is a performance cliff.

5. Apply vetted changes under the [mysqld] section of the server configuration file.

   [mysqld]
   innodb_buffer_pool_size = 8G
   thread_cache_size = 64
   table_open_cache = 4096

   Configuration file locations vary, commonly /etc/mysql/mysql.conf.d/mysqld.cnf for MySQL on Debian-style layouts and /etc/mysql/mariadb.conf.d/50-server.cnf for MariaDB.

6. Restart the database service when a persisted change requires it.

   $ sudo systemctl restart mysql

   On systems where MariaDB runs as mariadb.service, use sudo systemctl restart mariadb.

   Restarting the database service drops existing connections and interrupts in-flight work.

7. Verify the new settings from SQL to confirm the server loaded the expected values.

   $ mysql -e "SHOW VARIABLES LIKE 'innodb_buffer_pool_size';"
   +-------------------------+------------+
   | Variable_name           | Value      |
   +-------------------------+------------+
   | innodb_buffer_pool_size | 8589934592 |
   +-------------------------+------------+

8. Re-run mysqltuner after changes to confirm warning reduction plus correct sizing.

   $ mysqltuner
   ##### snipped #####
   -------- Recommendations -----------------------------------------------------
   General recommendations:
       Consider increasing thread_cache_size to reduce Threads_created
   ##### snipped #####

   Compare before/after counters such as Innodb_buffer_pool_reads and Threads_created to validate improvement.