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

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

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

Рабочая схема обычно такая:
— секционируем по признаку, который почти всегда есть в WHERE: дата, tenant_id, статус с низкой кардинальностью редко подходит;
— следим за partition pruning: без него пользы мало;
— не забываем про локальные и глобальные индексы: локальные проще обслуживать, глобальные иногда нужны, но могут дорого стоить в DML;
— планируем жизненный цикл данных: удаление старых секций быстрее, чем DELETE по строкам. Посмотрим, что тут с I/O в реальности.

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

Золотое правило: сначала мониторинг, потом индексы. Сначала проверьте, какие запросы реально выигрывают от pruning, какие секции читаются, и как ведут себя INSERT/UPDATE/DELETE. Если partitioning не уменьшает объём чтения или не упрощает purge, он вам не помощник, а дополнительный слой сложности.