Приходилось ли вам заниматься оптимизацией запросов?

Да, приходилось. Оптимизация запросов — важная часть разработки высокопроизводительных приложений.

Мой опыт включает:

• Анализ плана выполнения запроса (EXPLAIN): Использование EXPLAIN для понимания, как база данных выполняет запрос, какие индексы используются и где возникают узкие места.
• Создание и оптимизация индексов: Добавление подходящих индексов к часто используемым столбцам и комбинированных индексов для ускорения фильтрации, сортировки и объединений. Удаление неиспользуемых или дублирующихся индексов.
• Переписывание неэффективных запросов:
  • Замена SELECT * на выборку конкретных столбцов.
  • Использование более подходящих типов объединений (JOIN) вместо подзапросов или вложенных циклов на уровне приложения.
  • Упрощение условий WHERE.
  • Избегание функций в условиях WHERE на индексированных столбцах.
  • Оптимизация GROUP BY и ORDER BY.
• Нормализация/денормализация: Применение нормализации для уменьшения избыточности или, в некоторых случаях, денормализации для ускорения чтения данных за счет дублирования или создания агрегированных столбцов (с осторожностью).
• Кэширование результатов запросов: Реализация кэширования на уровне приложения или использование механизмов кэширования базы данных (например, Redis, Memcached) для снижения нагрузки на БД при чтении часто запрашиваемых, редко изменяющихся данных.
• Ограничение выборки данных: Использование LIMIT для пагинации или выборки только необходимого количества записей.
• Мониторинг и профилирование: Использование инструментов мониторинга (например, Percona Monitoring and Management, phpMyAdmin с включенным Slow Query Log) для выявления медленных запросов.

Приведу пример анализа с EXPLAIN:

// Пример медленного запроса без индекса на столбце status
SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();

// Анализ плана
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Может показать полный скан таблицы (ALL) или неиспользование подходящего индекса.

// Добавление составного индекса на оба столбца
CREATE INDEX idx_status_created_at ON orders (status, created_at);

// Повторный анализ после создания индекса
EXPLAIN SELECT * FROM orders WHERE status = 'pending' AND created_at < CURDATE();
// Ожидается, что тип (type) изменится на ref или range, и Extra будет содержать "Using where;"