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

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

Коллеги, давайте разберем план выполнения. Partitioning полезен, когда запросы почти всегда режут данные по одному признаку: дате, tenant_id, региону. Тогда движок может отрезать лишние секции и меньше читать с диска. Но если фильтр не совпадает с ключом секционирования, получите тот же full scan, только по множеству кусков. Посмотрим, что тут с I/O в реальности.

Главные ошибки:
— делают секции «на всякий случай», хотя запросы ходят по статусу и user_id;
— ставят слишком мелкие границы и получают сотни объектов вместо одной таблицы;
— забывают про глобальные/локальные индексы и потом удивляются, почему INSERT стал тяжелее;
— не проверяют, что pruning вообще срабатывает в типовых запросах.

Схема простая, но дьявол кроется в статистике. Без актуальных данных по секциям оптимизатор легко промахнется с планом и выберет лишние чтения. Еще один любимый сюрприз — операции обслуживания: drop, merge, split, rebuild. В продакшене так лучше не делать, и вот почему: если окно записи плотное, секционирование может добавить блокировки и заметный оверхед на администрирование.

Золотое правило: сначала мониторинг, потом индексы. Смотрите на планы, объем реально читаемых строк, частоту обслуживания и то, можно ли жить без секционирования вообще. Если выигрыш только в теории — таблица без секций обычно дешевле в сопровождении.