Секционирование не лечит медленные запросы: сначала проверьте, за что платит план

Секционирование не лечит медленные запросы: сначала проверьте, за что платит план

Коллеги, давайте разберем план выполнения. Partitioning полезен, когда таблица растет, а запросы почти всегда бьют в ограниченный диапазон по дате, статусу или tenant_id. Тогда работает pruning: СУБД просто не трогает лишние куски данных. Если же фильтр не совпадает с ключом секций, получите красивую схему и тот же full scan, только по частям.

Типовые ошибки:
— секционируют «на всякий случай», без измеримого hot path;
— выбирают ключ, который редко участвует в WHERE;
— делают слишком мелкие секции и потом тонут в накладных расходах на планирование, статистику и обслуживание;
— забывают, что индекс внутри секции не заменяет нормальный доступ по предикату.

Посмотрим, что тут с I/O в реальности. Если запросы ходят в одну-две секции, выигрывают и чтение, и vacuum/merge/архивация старых данных. Если же отчеты сканируют все секции подряд, partitioning часто добавляет лишнюю сложность: больше объектов, дольше DDL, больше шансов поймать блокировки на обслуживании. В продакшене так лучше не делать, и вот почему: секции — это инструмент локализации проблем, а не магическая кнопка ускорения.

Перед внедрением проверьте три вещи: есть ли стабильный фильтр для pruning, можно ли без боли удалять/архивировать старые данные, и не сломает ли схема загрузку/репликацию/джобы обслуживания.

Золотое правило: сначала мониторинг, потом индексы; секционирование — после того, как поняли, где именно таблица жжет I/O и зачем вам эта архитектурная сложность.