我们有一个带有120m行的表（超过2222个微分十字），该表具有2个重要列，record_id，值为 prefix|<account_id>|<uuid>（unique）和counter_ID，其值为<account_id>。请注意，所有记录的前缀相同。当然，当然是一些事实列，但这与此无关。
Snowflake通过clustering_information函数显示record_id列的完美聚类（由SF自动选择，未由我们设置指定的聚类）：
"total_partition_count" : 2222,
"total_constant_partition_count" : 2222,
"average_overlaps" : 24.0,
"average_depth" : 25.0,
然而，对于列counture_id，群集非常糟糕
"total_constant_partition_count" : 0,
"average_overlaps" : 2221.0,
"average_depth" : 2222.0,
大约有130个不同的帐户ID，这意味着一个Account_ID的记录应超过17个分区。即使雪花簇按记录_ID簇，该列的开头（prefix|<account_id>）与account_id列相关。因此，具有相同帐户的记录应最终进入同一分区。因此，我无法弄清楚为什么Account_ID列有100％重叠的微分类。就像雪花对record_id列使用了一些奇怪的排序，因此每个分区中每个帐户的散布行。这可能吗？
这对性能产生负面后果，因为使用coundy_id滤波器进行查询会导致所有分区的扫描。
注意：还在雪花论坛上提出了这个问题has-terible
在Snowflake的聚类报告功能中，如上所述，只有一个限制，只有VARCHAR的前6个字符才被考虑用于评估聚类深度。因此，我不会相信record_id报告的出色结果，因为即使后续帐户是随机的，前6个字符也可能是由于前缀而相同的。
最好的解决方案是明确声明councel_id上的聚类并激活表上的自动聚类。