1. Индексируй под реальные паттерны запросов (композитные, селективные, covering-индексы), а не просто по числу строк. Следи, чтобы статистика была актуальной.
2. Используй
EXISTS для проверки наличия данных; COUNT(*) — только если реально нужен подсчёт. 3. Выбирай конкретные колонки, не пиши SELECT *, чтобы сократить I/O и дать шанс использовать covering-индекс.
4. Пиши sargable-предикаты (которые могут использовать индекс). Медленные коррелированные подзапросы лучше переписать через JOIN или EXISTS.
5. Не лечи ошибки DISTINCT’ом. Исправь логику JOIN и ключи; DISTINCT — только когда реально нужно убрать дубликаты.
6. Фильтруй в
WHERE, а HAVING используй только для условий после агрегации. 7. Пиши явные
JOIN ... ON, не лепи неявные join’ы через WHERE. 8. Используй keyset pagination вместо OFFSET/LIMIT на больших наборах; для выборки подмножества можно применить TABLESAMPLE (если поддерживается).
9. Предпочитай
UNION ALL вместо UNION, если дубликаты допустимы. 10. Заменяй широкие
OR на UNION ALL, только если каждая ветка может использовать свой индекс. 11. Тяжёлые запросы запускай вне пиковых часов, при возможности — ограничивай ресурсы или ставь в очередь.
12. Избегай
OR в условиях JOIN, можно использовать вычисляемые колонки или UNION ALL, если это позволит использовать индекс. 13. Используй
GROUP BY, когда нужны агрегированные строки, и оконные функции — когда нужно видеть строки с агрегатами рядом. 14. Используй временные/derived таблицы, если они реально сокращают работу или добавляют статистику; но помни, что это может заблокировать pushdown-оптимизации.
15. При массовой загрузке данных отключай/удаляй некластерные индексы, вставляй пакетами, потом перестраивай. PK/кластерный индекс можно оставить, если помогает.
16. Используй материализованные представления для редко меняющихся и дорогих агрегатов, продумай их обновление и инвалидацию.
17. Избегай не-sargable сравнений (например, <>) по малоселективным колонкам; лучше перепиши в диапазоны.
18. Минимизируй коррелированные подзапросы на больших выборках, переходи на join’ы или EXISTS.
19. Выбирай
INNER или LEFT/RIGHT по смыслу, но помни: INNER JOIN обычно быстрее, если подходит по логике. 20. Кешируй часто повторяющиеся выборки: временные таблицы (на сессию), result cache или материализованные представления с продуманными правилами обновления.
Что такое Query Optimizer
Query Optimizer — это компонент СУБД, который определяет наиболее эффективный способ выполнения SQL-запроса, подбирая оптимальный execution plan.
Он принимает SQL-запрос, парсит его и строит синтаксическое дерево. Затем анализирует дерево, чтобы понять, какие способы выполнения возможны.
Далее оптимизатор генерирует альтернативные execution plans — разные варианты выполнения одного и того же запроса. В каждом плане задаётся:
- порядок доступа к таблицам
- типы соединений
- способы фильтрации и сортировки
Каждому плану присваивается стоимость — оценка по числу чтений с диска, времени CPU и другим факторам.
После этого оптимизатор выбирает план с минимальной стоимостью и использует его для реального выполнения запроса.
Узнай больше
👉 Java Portal