Секционирование таблиц: когда ускоряет запросы, а когда только усложняет жизнь

Секционирование таблиц: когда ускоряет запросы, а когда только усложняет жизнь

Коллеги, давайте разберем план выполнения. Partitioning полезен, когда запросы почти всегда бьют в узкий диапазон данных: по дате, региону, статусу. Тогда оптимизатор может отрезать лишние секции и читать меньше страниц. Но если фильтры размытые, а джоины идут по «широким» условиям, секционирование часто добавляет только лишнюю сложность.

Что проверить до внедрения:
— есть ли стабильный ключ секционирования, который реально присутствует в WHERE;
— не станет ли одна секция «горячей» и не убьет ли параллелизм;
— как поведут себя INSERT/UPDATE/DELETE: иногда выигрыш на чтении съедается стоимостью записи;
— нужны ли глобальные уникальные ограничения и как их вообще будет проверять СУБД.

Посмотрим, что тут с I/O в реальности. Если таблица большая, а отчеты ходят по последним периодам, секции помогают не магией, а банальным сокращением объема скана. Но если статистика по секциям не обновляется, план легко уедет в полный проход. Схема простая, но дьявол кроется в статистике.

Перед разбиением обязательно прогоните реальные запросы с EXPLAIN/ANALYZE и посмотрите, есть ли partition pruning, сколько секций читается и не растет ли число блокировок на обслуживании. В продакшене так лучше не делать вслепую: сначала измеряем, потом режем таблицу.