Как ответить
Оптимизация баз данных — это моя повседневная задача. В основном работаю с PostgreSQL, немного с MySQL. Типичная ситуация: приложение тормозит, админы жалуются, нужно быстро найти причину и исправить. Обычно проблема не в самой БД, а в неэффективных запросах или отсутствии индексов.
Мой подход — начинать с мониторинга. В PostgreSQL использую pg_stat_statements, чтобы найти самые медленные запросы. Дальше EXPLAIN ANALYZE — смотрю, где идёт Seq Scan по большой таблице, где не хватает индекса. Например, в одном проекте был запрос поиска заказов с фильтрацией по дате и статусу. EXPLAIN показал full scan на таблице в 5 млн строк. Добавил составной индекс (status, created_at) — время выполнения упало с 2 секунд до 40 мс.
Бывает, нужна денормализация. Когда на чтение идёт много JOIN'ов, которые тяжело индексировать. В одном сервисе отчётности мы добавили материализованные представления, обновляемые раз в час. Это снизило нагрузку с 80% CPU до 15%.
Ещё важный момент — партиционирование больших таблиц. Когда логов накапливается больше 100 млн строк, индексы перестают помещаться в память. Разбил по месяцам — время сканирования уменьшилось вдвое, потому что запросы редко выходят за текущий квартал.
Настройка пула соединений — тоже базовая вещь. На проекте с высоким конкурентным доступом (сотни реквестов в секунду) без PgBouncer БД просто падала от перегрузки соединениями. Поставил PgBouncer, настроил pool_size — количество активных коннектов снизилось с 200 до 30, а throughput вырос.
Из неочевидного: недавно ускорил ETL-процесс, заменив многочисленные INSERT'ы на COPY и временно отключив индексы на время загрузки. Запись стала быстрее в 10 раз. Потом перестраивал индексы — это заняло минуту, но общее время загрузки сократилось с 2 часов до 15 минут.
В общем, каждая задача уникальна, но алгоритм похож: замеряем текущее состояние, находим узкое место, пробуем индексы, потом запросы, потом архитектуру.