С чего начать оптимизацию MySQL
Оптимизация MySQL — это не про магические параметры в конфигурации. Это системная работа: анализ медленных запросов, проверка индексов, настройка памяти под конкретную нагрузку и мониторинг. Слепое копирование чужих настроек my.cnf чаще вредит, чем помогает. Сначала измеряйте, потом меняйте.
Анализ и оптимизация запросов
90% проблем с производительностью кроются в неоптимальных запросах. Включите лог медленных запросов (slow_query_log) и анализируйте его с помощью pt-query-digest или встроенных инструментов мониторинга. Смотрите на: полные сканирования таблиц (Full Scan), неправильное использование индексов, временные таблицы на диске.
Используйте EXPLAIN для каждого подозрительного запроса. Обращайте внимание на тип доступа (type): const, ref, range — хорошо, ALL — плохо. Ключевые ошибки: SELECT * без необходимости, сложные JOIN без индексов, подзапросы в WHERE.
Правильная работа с индексами
Индексы ускоряют чтение, но замедляют запись. Добавляйте их обдуманно. Составные индексы должны учитывать порядок колонок и тип запросов. Избегайте избыточных индексов — они занимают память и замедляют обновления.
Типовые ошибки: индексы по колонкам с низкой селективностью (например, пол с значениями М/Ж), слишком длинные индексы по текстовым полям, отсутствие индексов для FOREIGN KEY.
Настройка конфигурации MySQL
Основные параметры в my.cnf, которые требуют внимания:
| Параметр | Рекомендация | Риски |
|---|---|---|
| innodb_buffer_pool_size | 70-80% от доступной RAM | Слишком большой размер может вызвать свопинг |
| innodb_log_file_size | 1-2ГБ для высокой нагрузки | Увеличение требует остановки сервера |
| max_connections | По факту нагрузки, но не более 1000 без необходимости | Завышение ведёт к потреблению памяти |
| thread_cache_size | Значение, равное max_connections | Недостаток — пересоздание потоков |
Не используйте query_cache_type в MySQL 8.0 и выше — этот механизм удалён. В более ранних версиях осторожно: при частых изменениях данных кэш запросов может снижать производительность.
Оптимизация схемы базы данных
Плохая схема не исправляется индексами. Нормализуйте данные, но без фанатизма — иногда денормализация ускоряет сложные выборки. Выбирайте правильные типы данных: INT вместо VARCHAR для числовых идентификаторов, DECIMAL вместо FLOAT для точных расчётов.
Разделяйте большие таблицы на партиции по дате или диапазону значений. Но партиционирование — не панацея: оно усложняет администрирование и не заменяет индексы.
Мониторинг и обслуживание
Настройте регулярный сбор метрик: количество запросов, использование буферного пула, операции ввода-вывода, блокировки. Используйте Percona Monitoring Tools, Prometheus с экспортером для MySQL или встроенные статусы.
Планируйте профилактику: проверка целостности таблиц, обновление статистик (ANALYZE TABLE), очистка бинарных логов и старых данных. Автоматизируйте эти задачи.
Частые ошибки и ограничения
Не увеличивайте всё подряд «на всякий случай». Лимиты оперативной системы, сетевые задержки и дисковая подсистема — частые узкие места. Виртуализация и облака добавляют свои накладные расходы: проверьте IOPS и latency дисков.
Остерегайтесь мифов: перестройка индексов каждый день, отключение всех проверок согласованности, ручная настройка всех параметров без измерений. MySQL давно стал умнее многих советчиков.
Вопросы и ответы
Как часто нужно перестраивать индексы в MySQL?
Индексы не требуют регулярного перестроения в современных версиях MySQL. InnoDB автоматически поддерживает их актуальность. Исключение — случаи сильной фрагментации после массовых операций DELETE/UPDATE, но это редкость при правильной первоначальной настройке.
Какие параметры my.cnf критичны для производительности?
innodb_buffer_pool_size (70-80% от доступной RAM), innodb_log_file_size, max_connections, query_cache_size (в версиях до 8.0) и thread_cache_size. Но слепое копирование чужих конфигов опасно — настройки зависят от нагрузки и аппаратных ресурсов.
Почему запрос с индексом всё равно выполняется медленно?
Возможные причины: неоптимальный тип индекса, недостаточная селективность, неправильный порядок колонок в составном индексе, временные таблицы на диске или блокировки. Требуется анализ выполнения через EXPLAIN.