Настройка производительности MySQL

Эта страница является оригинальной документацией PmaControl. Она сохраняет практичную структуру индекса для работ по оптимизации MySQL, не копируя сторонний контент и не завися от внешнего продукта.

Цель

Настройка MySQL снижает задержку, стабилизирует пропускную способность и предотвращает повторяющиеся насыщения. Работа должна начинаться с реальных измерений, а не с универсальных значений, скопированных с другого сервера.

Рекомендуемый порядок работ

1. Снять реальную нагрузку: QPS, задержку, ошибки, соединения, дисковый I/O, память и CPU.
2. Найти доминирующие запросы через performance_schema, slow log или digest-инструмент.
3. Проверить схему: отсутствующие индексы, лишние индексы, слишком широкие типы, таблицы без первичного ключа.
4. Настроить InnoDB: buffer pool, redo log, flush, I/O threads и стратегию долговечности.
5. Проверить лимиты сервера: соединения, открытые файлы, кэши таблиц и размеры временных таблиц.
6. Тестировать в контролируемое окно с документированным rollback.

Полезные команды

SHOW GLOBAL STATUS LIKE 'Threads_connected';
SHOW GLOBAL STATUS LIKE 'Questions';
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
SHOW VARIABLES LIKE 'innodb_buffer_pool_size';

Главное

Хорошая настройка MySQL выполняется постепенно. Переменная, измененная без измерений до и после, становится операционным долгом.

Соберите сопоставимые исходные данные

Зафиксируйте точную версию сервера, ресурсы узла, размер данных, версию приложения, состав нагрузки и период наблюдения. Отделяйте время ответа клиенту от выполнения SQL: очередь пула соединений, сеть и работа приложения могут определять задержку даже при быстрых запросах. До и после изменения используйте одинаковую нагрузку и параллелизм.

SELECT VERSION() AS server_version, @@version_comment AS distribution;
SHOW GLOBAL STATUS WHERE Variable_name IN (
  'Uptime', 'Questions', 'Threads_connected', 'Threads_running',
  'Innodb_buffer_pool_read_requests', 'Innodb_buffer_pool_reads',
  'Innodb_log_waits', 'Created_tmp_tables', 'Created_tmp_disk_tables'
);

Снимите показатели дважды за репрезентативный интервал. Questions — накопительный счётчик: частота клиентских инструкций = ΔQuestions / время в секундах. Перезапуск или сброс делает интервал недействительным. Вместе с выполненной работой и ошибками фиксируйте p50, p95 и p99 задержки: снижение среднего может скрывать ухудшение хвоста.

Найдите запросы, расходующие ресурсы

SELECT SCHEMA_NAME, LEFT(DIGEST_TEXT, 140) AS digest,
       COUNT_STAR AS executions,
       ROUND(SUM_TIMER_WAIT / 1000000000000, 3) AS total_seconds,
       ROUND(AVG_TIMER_WAIT / 1000000000, 3) AS average_ms,
       SUM_ROWS_EXAMINED, SUM_ROWS_SENT
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST IS NOT NULL
ORDER BY SUM_TIMER_WAIT DESC
LIMIT 10;

Этот запрос MySQL Performance Schema ранжирует накопленное время, а не p95 недавнего окна. Таймеры выражены в пикосекундах. Проверьте инструментацию и историю сбросов: пустой результат не доказывает отсутствие нагрузки. Частые короткие запросы могут обходиться дороже одного медленного. Сопоставьте просмотренные и возвращённые строки, затем исследуйте типичные параметры через EXPLAIN FORMAT=JSON. EXPLAIN ANALYZE выполняет инструкцию: используйте контролируемую среду и поддерживаемую версию.

Выберите действие по узкому месту

Проверяйте по одному изменению

Запишите гипотезу, прежнее значение или схему, ожидаемый результат и условие отката. Одинаково прогревайте кеши, повторяйте репрезентативные испытания и сохраняйте исходные результаты. Совместно сравнивайте задержки, производительность, ошибки, CPU, память, I/O и отставание реплики. Отклоняйте ускорение ценой корректности, надёжности или других важных нагрузок. Перепроверьте результат на пике и за полный бизнес-цикл.

Продолжение диагностики

• Проверка состояния определяет доступность и запас ресурсов.
• Проверка схемы и параметры производительности помогают выбрать точечные изменения.

Официальные источники

• MySQL Performance Schema
• MySQL EXPLAIN