С чего начать оптимизацию 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.