MySQLTuner — Perl-скрипт, который подключается к серверу MySQL или MariaDB, читает статусные переменные и переменные конфигурации, а на выходе даёт список рекомендаций. Отчёт удобен для быстрой проверки, но часть советов в нём рассчитана по универсальным формулам без учёта реальной нагрузки конкретного сайта. Разберём, каким пунктам отчёта можно доверять, а какие сначала нужно проверить руками.
Когда запускать MySQLTuner, а когда не стоит
Сервер должен поработать под обычной нагрузкой минимум сутки, а лучше неделю — только тогда статусные переменные (Questions, Threads_connected, Created_tmp_disk_tables) отражают реальную картину. Сразу после перезапуска MySQL большинство счётчиков равны нулю или малы, и отчёт выдаст советы, построенные на случайных числах.
Запуск сразу после миграции базы, смены версии MySQL или на сервере, где кроме базы работает веб-сервер и PHP-FPM с ограниченной оперативной памятью, даёт отчёт, в котором рекомендации по буферам рассчитаны без оглядки на других потребителей памяти — об этом подробнее в разделе про зря даваемые советы.
Как получить отчёт
Скрипт запускают с правами пользователя, у которого есть доступ к SHOW GLOBAL STATUS и SHOW GLOBAL VARIABLES; обычно это root MySQL или отдельный аккаунт только с правом PROCESS и SELECT на служебные таблицы.
wget http://mysqltuner.pl/ -O mysqltuner.pl
perl mysqltuner.pl --user root --pass PASSWORDВывод разбит на два блока: General recommendations — текстовые советы, и Variables to adjust — конкретные переменные конфигурации с предложенными значениями. Второй блок менять только после проверки первого: совет без понимания причины создаёт новую проблему вместо старой.
Какие рекомендации стоит проверять руками
Часть пунктов отчёта напрямую связана со статистикой, которую стоит пересчитать по актуальным данным, а не принимать на веру:
- Соотношение
Created_tmp_disk_tablesкCreated_tmp_tables— высокая доля дисковых временных таблиц означает, что запросы сGROUP BYилиORDER BYне укладываются вtmp_table_size, и рекомендацию поднять лимит стоит проверить через лог медленных запросов, а не применять вслепую. - Процент попаданий в буферный пул (
Innodb_buffer_pool_readsпротивInnodb_buffer_pool_read_requests) — низкий показатель на свежем сервере — это норма: кэш ещё не прогрелся. - Пиковое число соединений (
Max_used_connections) противmax_connections— совет снизить лимит имеет смысл только если пик стабильно низкий на протяжении нескольких дней, а не одного измерения. - Наличие таблиц MyISAM — совет перевести их в InnoDB верный почти всегда, но сначала стоит проверить, не используют ли эти таблицы полнотекстовый поиск старого формата, который при переносе ведёт себя иначе.
- Размер
thread_cache_size— рекомендация поднять его полезна при частых коротких соединениях (PHP без persistent-подключений), и бессмысленна при пуле постоянных соединений.
Общее правило: любой совет из отчёта имеет смысл сверить с планом конкретных запросов — здесь поможет разбор через EXPLAIN, а не изменение переменной вслепую.
Какие советы MySQLTuner даёт зря
Главный источник ложных рекомендаций — расчёт буфера InnoDB от объёма оперативной памяти, который скрипт видит через /proc/meminfo. На виртуальном сервере, где кроме MySQL работает Nginx, PHP-FPM и Redis, вся свободная память не принадлежит одной базе, а MySQLTuner формулой этого не знает.
| Совет из отчёта | Что видит скрипт | Что нужно учесть |
|---|---|---|
| Поднять innodb_buffer_pool_size до 70-80% RAM | Общий объём оперативной памяти сервера | Сколько памяти уже занято PHP-FPM, Nginx и другими службами |
| Включить query cache | Старую переменную query_cache_type | В MySQL 8.0 query cache убран из кода — совет относится только к MySQL 5.7 и MariaDB |
| Увеличить table_open_cache до нескольких тысяч | Текущее число открытых таблиц | Лимит открытых файлов в системе (ulimit -n), который нужно поднять одновременно |
| Снизить max_connections | Разовый пик Max_used_connections | Нагрузку в часы пик за несколько дней, а не один замер |
Перед тем как менять innodb_buffer_pool_size, стоит свериться с планом нагрузки на сервер и с индексами самих таблиц — лишний буфер не ускорит запрос без нужного индекса.
Как проверить результат после правок
Сразу после изменения переменной в конфигурации MySQL перезапускают сервис и следят за логом ошибок первые минуты: неверное значение буфера чаще всего проявляется как отказ запуска, а не как медленная работа.
Через сутки-двое стоит запустить MySQLTuner повторно и сравнить соотношение попаданий в буферный пул и долю дисковых временных таблиц с показателями до правок — это честнее, чем ориентироваться на один прогон отчёта.
Частые вопросы
Можно ли запускать MySQLTuner на рабочем сервере без риска?
Да, сам скрипт только читает статусные переменные и ничего не меняет в конфигурации; риск возникает только когда администратор применяет предложенные значения без проверки. Запуск самого отчёта безопасен и не создаёт нагрузки, заметной на живом сайте.
MySQLTuner советует поднять innodb_buffer_pool_size почти до объёма всей оперативной памяти — это правильно?
Только на выделенном сервере, где кроме MySQL больше ничего не работает. На сервере с Nginx, PHP-FPM и другими службами такой буфер оставит слишком мало памяти остальным процессам, и при пиковой нагрузке систему начнёт выгружать в swap, что медленнее любого промаха кэша.
Нужно ли сразу выполнять все пункты с отметкой [--!!]?
Нет, эта отметка означает только высокий приоритет внутри формулы скрипта, а не проверенную причину проблемы на конкретном сервере. Каждый такой пункт стоит сверить со статистикой за несколько дней и с логом медленных запросов, а не выполнять по списку сверху вниз.