Абсолютное количество строк в разделе не самая полезная метрика.Что вам действительно нужно, так это столбец, который стабилен по мере роста таблицы и который обеспечивает потенциальные преимущества секционирования.Это: доступность, управление табличным пространством и производительность.
Например, в вашем столбце с примерами есть три значения.Это означает, что вы можете иметь три раздела, что означает, что вы можете иметь три табличных пространства.Поэтому, если табличное пространство становится поврежденным, вы теряете треть своих данных.Делает ли разделение вашу таблицу более доступной?Не совсем.
Добавление или удаление раздела облегчает управление большими объемами данных.Но можете ли вы когда-нибудь сбросить все строки со статусом WORKED_CORRECTLY?Очень маловероятно.Делает ли разделение вашу таблицу более управляемой?На самом деле, нет.
Преимущества секционирования в производительности заключаются в сокращении запросов, когда оптимизатор может сразу сбрасывать со счетов части таблицы.Теперь у каждого раздела 1,3 миллиона строк.Так что даже если вы сделаете запрос на STATUS='WORKED_CORRECTLY', у вас все еще есть огромное количество записей, которые вы сможете узнать.И есть вероятность, что любой запрос, в котором не используется STATUS, будет работать хуже, чем в случае неразделенной таблицы.Делает ли разделение вашу таблицу более производительной?Наверное, нет.
До сих пор я предполагал, что ваши разделы распределены равномерно.Но ваш последний вопрос показывает, что это не так.Большинство строк, если не все, заканчиваются на WORKED_CORRECTLY.Таким образом, этот раздел станет огромным по сравнению с другими, и шансы на преимущества от разделения станут еще более отдаленными.
Наконец, предложенная вами схема не является эластичной.Поскольку текущий объем каждого раздела будет иметь 1,3 миллиона строк.Когда ваша таблица увеличится до сорока миллионов строк, каждый раздел будет содержать 13,3 миллиона строк.Это плохо.
Итак, что делает хорошего кандидата на ключ раздела?Один, который производит много разделов, один, где разделы примерно равны по размеру, один, где значение ключа вряд ли изменится, и другой, где значение имеет некоторое значение в жизненном цикле базового объекта, и, наконец, тот, которыйполезен в большинстве запросов к таблице.
Вот почему что-то вроде DATE_CREATED является таким популярным выбором для разделения таблиц фактов в хранилищах данных.Он генерирует разумное количество разделений по ряду гранулярностей (обычно выбираются день, месяц или год).Мы получаем примерно одинаковое количество записей, созданных за данный промежуток времени.Загрузка данных и архивирование данных обычно выполняются на основе возраста (то есть даты создания).BI-запросы почти всегда включают измерение TIME.