3.4 KiB
3.4 KiB
| aliases | tags | date | zero-link | parents | linked | |||||
|---|---|---|---|---|---|---|---|---|---|---|
|
|
|
|
Что такое плохой или медленный запрос
- Запрос по времени работает дольше остальных
- Запрос, который потребляет больше ресурсов, чем остальные запросы
- Быстро выполняемый запрос может быть также плохим, если выполняется часто и в сумме за N времени потребляет много ресурсов.
Алгоритм оптимизации запросов:
- Проверить настройки. Возможно проблемы не связаны с запросами?
- Слабое железо у сервера БД
- Проблемы сети
- Неправильные настройки БД
- PostgreSQL
- Много конекшенов, но ее используется PgBouncer.
- Выключен или не настроен autovacuum
- PostgreSQL
- Отобрать запросы для оптимизации
- ==Анализом необходимо заниматься только на продуктовой БД.==
- Все подряд оптимизировать бесполезно. Нужно отобрать самые проблемные и начать с них.
- PostgreSQL
- Использовать GitHub - Полезные утилиты для тюнинга PostgreSQL - global_reports
- Использовать pg_stat_statements
- PostgreSQL
- Оптимизировать запросы
- Использовать Explain в PostgreSQL и Explain в MySQL для анализа запросов
- Повторить с новыми запросами из топа.
Где могут быть проблемы?
- Передача запроса от клиента (сервиса). Пример при использовании IN
- Сложный запрос, который долго парсится. Можно посмотреть в explain.
- БД долго вычисляет план запроса и проводит оптимизации. Например, при использовании join.
- Исполнение и возврат результатов. Если вы возвращаете несколько гигабайт, это не будет быстро.
Как улучшить?
- Переписать запрос
- Использовать Индексы в MySQL / Индекс в PostgreSQL
Невозможно улучшить
- count(*). Можно использовать приближенное значение из таблицы статистики.
- join на 300 таблиц
- Запрос возвращает клиенту 1 000 000 000 строк
