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

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

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

Чаще всего partitioning полезен для больших таблиц с жизненным циклом данных: логов, событий, историй статусов. Тогда старые секции можно быстро архивировать или удалять через detach/drop, а не гонять гигантский DELETE с блокировками и мусором в журнале. Но если основной запрос ищет по customer_id, а секции нарезаны по дате — pruning не спасет.

Посмотрим, что тут с I/O в реальности: перед внедрением проверьте, есть ли у вас частые сканы, долгие очистки и перекос по горячим данным. И не забывайте про индексы на каждой секции, рост планов обслуживания и риск, что «простое» удаление превращается в конструктор.

Схема простая, но дьявол кроется в статистике: сначала измерьте, потом режьте таблицу. Если секции не участвуют в фильтрации или обслуживании, partitioning добавит только лишнюю операционную сложность.