即。如果我们有一个400万行的表。
其中STATUS字段可以采用以下值：TO_WORK，BLOCKED或WORKED_CORRECTLY。
你会在一个只会改变一次的字段上进行分区（大部分时间从to_work变为working_correctly）吗？你会创建多少个分区？
答案 0 :(得分：15)
分区中的绝对行数不是最有用的指标。你真正想要的是一个随着表的增长而稳定的列，它提供了分区的潜在好处。它们是：可用性，表空间管理和性能。
例如，您的示例列有三个值。这意味着您可以拥有三个分区，这意味着您可以拥有三个表空间。因此，如果表空间损坏，您将丢失三分之一的数据。分区是否使您的桌子更有用？不是真的。
添加或删除分区可以更轻松地管理大量数据。但您是否有可能删除状态为WORKED_CORRECTLY的所有行？不大可能。分区是否使您的表更易于管理？并不是的。
分区的性能优势来自查询修剪，优化器可以立即对表的块进行折扣。现在每个分区有130万行。所以，即使你在STATUS='WORKED_CORRECTLY'上查询，你仍然有大量的记录要进行。并且机会是，任何不涉及STATUS的查询都将比未分区的表执行得更糟。分区是否使您的表更具性能？可能不是。
到目前为止，我一直假设你的分区是均匀分布的。但是你的最后一个问题表明情况并非如此。大多数行（如果不是全部）行将最终出现在WORKED_CORRECTLY中。因此，与其他分区相比，分区将变得巨大，分区带来的好处变得更加遥远。
最后，您提出的方案不具有弹性。由于当前卷每个分区将有130万行。当您的表总共增长到四千万行时，每个分区将容纳1330万行。这很糟糕。
那么，什么才能成为分区键的合适人选呢？一个产生大量分区的分区，一个分区的大小大致相等，一个分区的值不太可能改变，一个分区在底层对象的生命周期中有一些含义，最后一个分区在针对表运行的大量查询中很有用。
这就是DATE_CREATED之类的东西在数据仓库中对事实表进行分区的流行选择。它在一系列粒度（一天，一个月或一年是常用选项）中生成合理数量的分区。我们在给定的时间跨度内创建的记录数大致相同。数据加载和数据存档通常基于年龄（即创建日期）来完成。 BI查询几乎总是包含TIME维度。
答案 1 :(得分：7)
表中的行数通常不是用于确定是否以及如何对表进行分区的重要指标。
你想解决什么问题？您是否尝试提高查询性能？数据加载的性能？清除数据的表现？
假设您正在尝试提高查询性能？您的所有查询都在STATUS列上有谓词吗？他们正在进行行的单行查找吗？或者您希望您的查询扫描整个分区？