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, що повільніше будь-якого промаху кешу.
Чи потрібно одразу виконувати всі пункти з позначкою [--!!]?
Ні, ця позначка означає лише високий пріоритет усередині формули скрипта, а не перевірену причину проблеми на конкретному сервері. Кожен такий пункт варто звірити зі статистикою за декілька днів і з журналом повільних запитів, а не виконувати за списком згори донизу.