企业官网建设流程全解析

做数据仓库这行久了，多少都遇到过一个让人挠头的场景：两张表都不算特别大，单表几亿行，各自单独跑个聚合也就十几秒，可一旦让它们按某个业务主键做 JOIN，耗时突然就窜到几分钟，甚至把内存打爆。第一反应通常是去查扫描量、看是不是没走分区裁剪、看是不是统计信息过期，结果查了一圈发现扫描端很健康，脏活全压在节点之间的数据传输上。StarRocks 的 Colocation Join 就是冲着这个痛点来的：它不改变 SQL，也不靠加机器，而是从数据的物理分布入手，让原本需要跨节点搬来搬去的 JOIN 变成每个节点自己算自己的那一段。这篇内容讲的就是它到底怎么做到这件事、建表时哪几个属性必须抠死、以及线上跑起来之后为什么有人明明写了参数却没生效。适合已经能写 StarRocks 建表语句、正在被大表 JOIN 拖慢的研发和数仓同学看，也适合想在选型阶段判断这个特性到底值不值得投入的人。

1. 分布式 JOIN 的瓶颈往往不在算力，而在数据搬家

1.1 一次 Shuffle Join 的成本账，比想象中贵得多

先把分布式 JOIN 的账算清楚，后面才知道 Colocate Join 省掉的是哪一块。假设左表 A 有 10 亿行、右表 B 有 2 亿行，两张表都按 32 个分桶散在 6 台 BE 上，现在按user_id做 INNER JOIN。在 MPP 执行框架下，最常见的做法是 Shuffle Join：把 A 和 B 都按user_id重新做一次哈希，把哈希值相同的行发到同一个节点上，然后在这个节点内部完成匹配。注意"重新做一次哈希"这几个字，它意味着 B 表的所有参与 JOIN 的列必须从磁盘读出来、经过序列化、走网络、在对端反序列化、再写进内存哈希表。2 亿行的右表如果每行参与 JOIN 的字段加起来 100 字节，光这一趟就是 20GB 的网络流量，这还没算左表。

更麻烦的是这条链路上每一个环节都可能成为瓶颈。网络带宽打满的时候，CPU 其实大部分时间在等 IO；哈希表构建阶段内存峰值上来，查询可能直接被内存限额掐死；为了缓解内存压力，优化器还可能把 Shuffle 降级成落盘的 Hash Join，多了一次磁盘读写，耗时再翻一倍。我在一个 3 节点的小集群上做过对比，同一份数据、同一个查询，Shuffle Join 阶段耗时几乎占了整个查询的 70%，真正做匹配的时间反而不多。这也解释了一个反直觉的现象：明明加了节点、加了核数，SHuffle JOIN 的耗时并没有线性下降，因为瓶颈在数据总量上，节点越多，跨节点的搬运组合反而越复杂。

Broadcast Join 是另一条路。当右表足够小（默认阈值受broadcast_row_limit这类参数约束），优化器会把整张右表广播到每个节点，每个节点拿着完整的右表哈希表和本地的左表分片做匹配。这条路省掉了左表的 Shuffle，但只要右表稍微大一点，广播的代价就会随节点数线性放大。6 个节点广播一张 2GB 的表就是 12GB 的流量，而且每个节点都要在内存里放一份完整副本，非常吃内存。所以 Broadcast 只适合真正的维表场景，右表一旦上到千万级就开始难受。

提示：判断当前查询用的是哪种 JOIN 方式，直接EXPLAIN看执行计划里 JOIN 节点的两侧有没有EXCHANGE算子。有EXCHANGE就说明数据在节点之间动了，动了就有网络开销；没有EXCHANGE而 JOIN 直接挂在两个扫描算子下面，才说明是本地执行。

这两条路的共同点是：它们都在"查询时"想办法。优化器根据统计信息估算哪边小、该广播还是该 Shuffle，但无论怎么选，数据的物理分布和查询需要的分布之间是有落差的，这个落差只能靠运行时搬运来填平。Colocate Join 的思路完全反过来——不是查询时搬数据，而是建表时就把数据放对位置，让"按某个键 JOIN"这件事在物理层面天然成立。

1.2 Colocate Join 的核心承诺：同键同桶，同桶同机

Colocate Join 的规则一句话可以说清：如果若干张表具有完全相同的分桶键、相同的分桶数量、相同的副本数，那么把分桶编号相同的那些数据块，强制放在同一组 BE 节点上。这样一来，当 JOIN 条件正好覆盖了分桶键时，键值相同的行必然落在同一个节点上，JOIN 完全可以在节点内部完成，一个字节的数据都不需要跨网络。这个机制在概念上不复杂，真正难的是保证"完全相同"这四个字在所有运维动作中始终成立，这也是后面所有坑的源头。

具体到 StarRocks 的实现，它引入了一个叫Colocation Group的逻辑概念。你可以把它理解成一个容器，容器里的表共享同一套分桶布局。每个表在物理上被切成若干个 Tablet，每个 Tablet 有一个从 0 开始的序号，叫Bucket Sequence（桶序号）。同一个 Group 内，所有表的第 N 号桶被约束在完全相同的 BE 集合上，而且主副本落在同一台机器上。JOIN 执行时，FE 下发的扫描任务会带上桶序号信息，A 表的 0 号桶和 B 表的 0 号桶被调度到同一个 BE 上，那个 BE 拿着两份本地数据就能直接算，省掉了 Shuffle 和 Broadcast 的全部成本。

这里有个容易被忽略的细节：省掉的不只是网络，还有序列化和反序列化。分布式执行里，跨节点的数据要打包成传输格式再解开，这部分 CPU 开销在列式存储上是相当可观的。本地 JOIN 直接读本地的列式数据，连编码转换都省了。所以实测中 Colocate Join 的收益往往比"省了网络流量"这个理由所暗示的还要大一些，尤其是在 JOIN 列比较少、但行数极多的场景下。

不过要说清楚它的边界。Colocate Join 只处理等值 JOIN，也就是ON a.k = b.k这种形式；它不解决非等值条件、不解决OR连接的多条件、也不改变聚合和排序的代价。它也是一个"静态收益"——一旦建表时分布定死了，后续每次查询都能吃到这个红利，不需要改 SQL。反过来说，如果建表时分布选错了，后面想改就得重建表重灌数据，成本不低。所以真正值得花时间的是建表前的那十分钟设计。

2. Colocation Group 的三层约束，以及它们为什么不能将就

2.1 分桶键必须与 JOIN 键对齐，这不是建议而是硬条件

很多人第一次用 Colocate Join 失败，原因就出在分桶键和 JOIN 键对不上。规则是这样的：参与 Colocate Join 的两张表，JOIN 条件里的等值列必须包含各自的分桶列。注意是包含，不是相等。比如 A 表DISTRIBUTED BY HASH(user_id, city_id)，B 表DISTRIBUTED BY HASH(user_id)，那么ON a.user_id = b.user_id这样的 JOIN 是可以命中的，因为两张表的 JOIN 键都覆盖了各自的分桶列；但如果 JOIN 条件只有ON a.city_id = b.city_id，就命中不了，因为 A 表的分桶列user_id没有被等值条件约束住，同一个city_id的行在 A 表里散落在多个桶中，本地匹配的前提不成立。

这个约束背后的原理其实很直白：分桶函数是对分桶列整体求哈希的。如果 JOIN 键只约束了分桶列的一部分，那么哈希值的分布就不可控，键相同的行不保证同桶。只有 JOIN 键完整覆盖分桶列时，hash(分桶列)的相等才能从 JOIN 键的相等推出来。所以设计时的正确顺序是：先把业务上最常用的 JOIN 键列出来，选那组出现频率最高、且数据类型稳定的列作为分桶列，而不是先随便定个分桶键再指望 JOIN 去适配。

数据类型的坑比这更隐蔽。分桶是对列值做哈希，INT和BIGINT虽然业务上都是整数，但底层编码宽度不同，哈希结果就不一样。如果 A 表分桶列是INT，B 表分桶列是BIGINT，即便 JOIN 时能隐式转换，桶的对齐关系也已经破坏了，这类查询通常会退化成 Shuffle Join 而不会报错，非常安静地把性能吃掉。VARCHAR的长度定义、字符集、CHAR和VARCHAR之间，也都存在同类问题。我的习惯是建表时把参与 Colocate 的键列类型写成完全一致的字面定义，然后交叉比对一遍建表语句，用不上隐式转换才安心。

还有一个更高频的踩坑点：NULL 值。分桶哈希对 NULL 的处理是固定的，JOIN 里 NULL 本来就不相等，两者不冲突，所以这块一般不用操心。真正要操心的是字符串的大小写和尾随空格，如果上游数据清洗不严，同一个业务键出现"ABC"和"abc"两种形态，哈希后落在不同的桶里，JOIN 时自然匹配不上——这是数据质量问题，但表现出来是"Colocate Join 结果不对"，容易误判成引擎 bug。

2.2 分桶数、副本数与分桶算法：三个必须一致的属性

除了分桶列，还有三个属性必须在同一个 Group 内保持一致，任何一项不一致，建表就会直接失败或者把表踢出 Group。

分桶数量必须一致。这个最直观：A 表 32 个桶，B 表 64 个桶，第 0 号桶在 A 表里覆盖的键空间是 B 表的 0 号和 32 号桶之和，没法一一对应。分桶数的选择有个经验区间，StarRocks 官方给的建议是单个 Tablet 的数据量控制在 1GB 到 10GB 之间，我自己的习惯是往这个区间的下半段靠，因为桶数多一些，单桶数据量小，本地 JOIN 时的哈希表更容易放进内存，也更容易在 BE 之间做均衡。但要提醒一句：分桶数不是越多越好。桶数上百之后，FE 的元数据管理、Tablet 的调度开销都会上升，而且小文件问题会变得明显。我一般按"总数据量 / (单桶目标 3GB) 后向上取到 2 的幂或者 3 的倍数"来估算。

副本数必须一致。副本数不同意味着同一个桶的副本集合规模不同，无法保证主副本落在同一台机器上。通常生产环境都是三副本，这个条件不太容易踩，但在测试环境为了省资源建了两副本表，再想和生产表放进同一个 Group，就会直接失败。

分桶算法必须一致。StarRocks 支持crc32和murmur3两种哈希算法，默认是crc32，可以在建表时通过PROPERTIES("bucket_hash_algorithm")指定。不同算法对同一个值的哈希结果完全不同，桶的对应关系自然就断了。这个属性的坑在于它不在建表语句的主干里，很容易被复制粘贴的建表模板带偏。我的做法是团队内统一一份建表模板，把分桶算法这一项显式写死，不给"默认值不一致"留空间。

2.3 分区对 Colocate Join 的影响，比文档写的更微妙

分区是这套机制里最容易让人困惑的部分。早期的规则很严格：两张表的分区列、分区数、分区范围必须完全一致，JOIN 才能真正本地化。原因不难理解——Colocation Group 定义的是"桶级别"的放置规则，而分区是在桶之上切的一层，如果 A 表切成 7 天分区、B 表切成 30 天分区，那么 A 表每一天的数据在物理上对应 B 表的多天数据，"同桶同机"这个约束就没法同时满足。

较新的版本对这块做了放宽，允许分区数不同的表之间做 Colocate Join，但代价是执行时会按分区粒度做对齐，某些情况下会退化成部分本地、部分 Shuffle 的混合模式。这个"放宽"是好事，但也制造了新的误判空间：你以为写了colocate_with就万事大吉，实际上执行计划里还是出现了EXCHANGE。所以我的建议是，无论版本怎么演进，都不要靠"应该支持了"来判断，而是每次都老老实实EXPLAIN看执行计划。

分区裁剪和 Colocate Join 是可以叠加的，而且叠加效果很好。假设两张表都按天分区，查询只扫最近三天，那么本地 JOIN 只在这三天的桶上发生，扫描量小、数据全在本地，这类查询的响应时间能做到秒级以内。反过来说，如果查询跨了全部历史分区，本地 JOIN 依然成立，只是数据量上去了，收益体现在"省掉 Shuffle"而不是"省掉扫描"上。

3. 从建表到验证：把 Colocate Join 真正跑通的动作清单

3.1 建表语句里那几个决定成败的属性和它们的写法

先给出一份可以直接抄的最小可用结构。假设订单明细表dwd_order_item和商品维表dim_product需要频繁按product_id做 JOIN，两张表都按天分区、三副本：

CREATE TABLE dwd_order_item ( dt DATE NOT NULL COMMENT "分区列", order_id BIGINT NOT NULL COMMENT "订单号", product_id BIGINT NOT NULL COMMENT "商品 ID", user_id BIGINT NOT NULL COMMENT "用户 ID", amount DECIMAL(18,2) NOT NULL COMMENT "金额" ) DUPLICATE KEY(dt, order_id, product_id) PARTITION BY RANGE(dt) ( PARTITION p20240101 VALUES [('2024-01-01'), ('2024-01-02')), PARTITION p20240102 VALUES [('2024-01-02'), ('2024-01-03')) ) DISTRIBUTED BY HASH(product_id) BUCKETS 32 PROPERTIES ( "replication_num" = "3", "bucket_hash_algorithm" = "crc32", "colocate_with" = "group_product_join" );

CREATE TABLE dim_product ( product_id BIGINT NOT NULL COMMENT "商品 ID", cate_id BIGINT NOT NULL COMMENT "类目 ID", brand VARCHAR(64) NOT NULL COMMENT "品牌", price DECIMAL(18,2) NOT NULL COMMENT "价格" ) DUPLICATE KEY(product_id) DISTRIBUTED BY HASH(product_id) BUCKETS 32 PROPERTIES ( "replication_num" = "3", "bucket_hash_algorithm" = "crc32", "colocate_with" = "group_product_join" );

几个要点值得单独强调。第一，colocate_with的值是 Group 名字，这个名字是全局的，第一次出现时自动创建 Group，后续同名表自动加入。名字建议带上业务前缀，避免不同团队撞名——撞名的后果是两张本来无关的表被塞进同一个 Group，然后因为分桶数不一致导致后建的那张直接失败。第二，DISTRIBUTED BY HASH(product_id) BUCKETS 32里的列和桶数必须在两张表里逐字相同，这是硬性要求。第三，bucket_hash_algorithm虽然两边都写crc32看起来多余（默认就是它），但显式写出来是防呆，防止将来有人改了集群默认值。

对于已经存在的表，可以用ALTER TABLE把表加入 Group，但有个前提：这张表当前不能属于任何 Group，而且它的分桶布局必须和目标 Group 完全匹配。写法是ALTER TABLE tbl_name SET ("colocate_with" = "group_name")。如果目标是退出 Group，把值设成空串即可。这个操作在线上是可以执行的元数据变更，但会触发数据重分布，数据量大的表要挑低峰期做，并且监控一下 BE 的 IO。

还有一条容易忽略的实操经验：Group 名字不要复用。如果一张表因为业务下线被删除，Group 里可能还留着别的表；如果你用同一个名字重建，新的表会自动加入旧 Group，而这时如果新表的分桶数按新需求调过，加入就会失败。名字里带一个版本后缀或者日期后缀，能省掉一堆排查时间。

3.2 用 EXPLAIN 和系统视图确认它到底生效了没有

建完表不等于生效，必须验证。最直接的手段是EXPLAIN，看 JOIN 节点的两侧有没有EXCHANGE：

EXPLAIN SELECT p.brand, sum(o.amount) FROM dwd_order_item o JOIN dim_product p ON o.product_id = p.product_id WHERE o.dt = '2024-01-02' GROUP BY p.brand;

命中 Colocate Join 时，执行计划里 JOIN 的两个子节点会直接是OlapScanNode，中间不出现EXCHANGE；部分版本的输出里 JOIN 节点会带一个colocate: true的标记。没命中的话，你能明确看到EXCHANGE算子夹在扫描和 JOIN 之间，或者看到partition: HASH PARTITION这类重分布描述。我的习惯是把这段执行计划保存成文本，和优化前的版本放在一起对比，网络算子消失了才算真的生效，而不是靠感觉"好像快了一点"。

第二个验证手段是看 Group 的状态：

SHOW PROC '/colocation_group';

这条命令会列出所有 Group 的GroupId、GroupName、BucketsNum、ReplicasNum、DistCol和IsStable。重点看两个字段：BucketsNum和ReplicasNum是否和你设计的一致，IsStable是否为true。IsStable = false意味着这个 Group 当前处于不可靠状态，此时即使 SQL 写得对，Colocate Join 也可能不生效或者结果不可预期。想看到每个桶具体落在哪台 BE 上，再执行SHOW PROC '/colocation_group/<GroupId>'，输出会按表、按桶列出对应的 BE 列表，肉眼就能确认"同序号桶是否同机"。

注意：IsStable为 false 是线上最常见的一类"不知道为什么没加速"的原因，而它往往不是建表时造成的，是运维动作造成的——副本修复中、BE 临时下线、新建表失败的残留，都会让它掉到 false。排查问题时这条命令应该是第一站，而不是最后一站。

4. 踩坑实录：从"完全没生效"到"Group 不稳定"的排查链路

4.1 查询写了参数却没命中的五种典型原因

有一次排查一个耗时从 40 秒退回到 4 分钟的查询，SQL 完全没改，表结构也没改，就是突然慢了。按顺序走了一遍检查，最后定位到是上游做了一次表重建，重建时漏掉了bucket_hash_algorithm属性，用了集群默认值，而集群默认值在那一周刚被运维调整过。这个案例很典型：Colocate Join 的失效往往不是"没配"，而是"配置在某次变更中被悄悄改掉了"。

我把这类问题整理成一张排查表，按命中率从高到低排：

第 5 条特别值得说一说。StarRocks 支持在 SQL 里用/*+ BROADCAST(t) */或/*+ SHUFFLE(t) */强制指定 JOIN 方式。这类 hint 的优先级高于优化器的 Colocate 判断，也就是说，只要 SQL 里写了SHUFFLE，哪怕分布完全正确，优化器也会乖乖去做 Shuffle。这在调优现场经常发生：某次为了解决数据倾斜，有人在 SQL 里加了强制 Shuffle 的 hint，问题解决了，hint 留在了代码里，后来表结构改造完成、Colocate Join 已经能生效，hint 却一直压着它。排查这类问题时，把 SQL 里的注释块整个检查一遍，往往比看执行计划更快。

还有一个安静的失效原因：JOIN 条件里带了函数。ON o.product_id = CAST(p.product_id AS BIGINT)这种写法，看起来类型对齐了，实际上函数包裹破坏了优化器对分桶键的识别，Colocate Join 判断直接放弃。同理，ON substring(o.key,1,10) = p.key之类的表达式匹配也不行。这类问题在执行计划里表现为正常出现EXCHANGE，不会报错，只能靠人眼盯 SQL。

4.2 表结构变更把 Group 打崩的几种姿势

分层数仓里表结构变更是常态，而 Colocate Group 对结构变更的容忍度比想象中低。下面这几种操作我都在真实环境里见过，每一种都带来过一段不短的排查时间。

第一种：改分桶数。分桶数是 Group 的组级属性，一张表改了，它就和其他成员不一致了。StarRocks 对修改分桶数的支持有限，通常的做法是重建表加数据迁移。所以建表时分桶数的估算要留出余量，宁可多留一些桶（单桶数据量偏小），也不要建完三个月发现数据涨了十倍再改。

第二种：改副本数。从三副本改成两副本，或者反过来，都会让表脱离 Group 的一致性约束。如果确实需要调副本数，得把 Group 里所有表一起调，而且要在IsStable恢复之后才算完成。

第三种：删除 Group 中的表。普通DROP TABLE会把表从 Group 中移除，这一步本身没问题。但如果有并发查询正在使用 Colocate Join，Group 的元数据变更可能让部分查询临时退化。更麻烦的是删除大表会触发大量 Tablet 的回收，回收期间 Group 可能短暂进入不稳定状态。稳妥的做法是低峰期删除，删完立刻查一次SHOW PROC确认状态。

第四种：给表加列。加列本身不影响分桶布局，是安全的。但如果加的是分桶列相关的位置（比如把分桶列改名），情况就复杂了，重命名分桶列会让 Group 的DistCol定义和表的实际列名对不上，可能导致整个 Group 不可用。我的经验是：分桶列一旦定下来，名字就别动，业务上需要更清晰的语义，走视图层去映射。

第五种：分区变更。动态分区、批量加分区这类操作，在较新版本里对 Colocate Join 是友好的，但如果是用TRUNCATE PARTITION清空数据再重灌，中间会有一段时间桶里没有数据，虽然不影响正确性，但如果两张表的重灌时间错得很开，查询性能会明显波动。生产上做这类操作，最好让两张关联表的分区重灌节奏对齐。

4.3 数据倾斜与副本均衡：本地 JOIN 也有它的软肋

这里要说一个反直觉的点：Colocate Join 把网络瓶颈消掉了，但它把数据倾斜的后果放大了。在 Shuffle Join 里，如果某个键特别热，这个键的行会被打散到多个节点上，压力相对分散（当然 Shuffle 之后的热点还是会跑到同一个 reducer）。而在 Colocate Join 里，热点键的所有行本来就集中在同一个桶、同一台 BE 上，本地计算意味着这台 BE 独自承担全部热点压力，其它 BE 可能在闲着。如果你的分桶键选的是那种分布极度不均的列，Colocate Join 的单点延迟可能比 Shuffle Join 还难看。

判断方法很直接：查一下分桶列的 TopN 分布。如果某个值占了全表 5% 以上，就要谨慎了。缓解手段有几种，最省事的是在分桶列里加入第二个高基数、低相关的列做复合分桶，把哈希空间打散；代价是 JOIN 条件必须同时覆盖这两个列才能命中，会影响后续查询的灵活性。另一种是接受倾斜，在业务层面对热点做拆解。

副本均衡是另一个维度。Colocate Group 的副本放置目标是"同序号桶同机"，这个约束和集群的负载均衡目标是冲突的——均衡器想让各 BE 的数据量接近，而 Colocate 约束限制了它可以挪动的自由度。StarRocks 提供了disable_colocate_balance这类开关来控制 Group 内部是否参与均衡。默认情况下均衡是开启的，在有充足空闲 BE 时它会尝试调整，调整过程中 Group 可能短暂不稳定。如果集群规模稳定、数据量又不算特别大，把 Group 内的均衡关掉能换来更稳定的状态；如果集群经常扩缩容，那还是让均衡工作，接受短时间的不稳定。

5. 收益量化与适用边界：什么时候值得上，什么时候别硬套

5.1 一个可复现的压测对比，以及数据背后说明了什么

为了给团队一个决策依据，我在一个 3 节点 BE（每节点 32 核、128GB 内存、SSD）的测试集群上做了一组对照。两张表：订单明细表 10 亿行、按product_id分成 32 桶；商品维表 800 万行、同样 32 桶。两种布局各跑三次取中位数，查询是一条按类目聚合的 JOIN。

这组数据里最值得注意的不是 8.9 秒和 38.7 秒的差距，而是内存那一列。Colocate Join 的峰值内存明显更低，因为它不需要在内存里维护跨节点传输的缓冲区和反序列化中间结果。这意味着同一台机器上能跑的并发查询数更多——单看一条查询的耗时可能只是三倍多的提升，但落到集群整体吞吐上，收益会被并发数再放大一轮。

另外还是要提醒一句，这是特定数据分布和查询形态下的结果。如果右表只有几千行，Broadcast 的开销本来就不大，Colocate Join 带来的相对提升会非常有限；如果查询本身带大量聚合、JOIN 只是很小的一环，那优化 JOIN 也救不了整体耗时。评估收益的正确方法是先看执行计划里EXCHANGE算子占了多少时间，占比大才值得动分布。

5.2 这些场景别硬上 Colocate Join

说完收益，更要说清楚不该用的地方，因为分布一旦定错，改起来是真费劲。

第一类：JOIN 键不固定的宽表分析。有些明细表要支持几十种不同的 JOIN 组合，今天是按用户、明天按商品、后天按门店。分桶列只能选一个组合，其它组合全部退化成 Shuffle。这类表强行上 Colocate Join，只会让那一个组合快，剩下的组合没有任何改善，还白白牺牲了分桶的灵活性。这种情况更适合保持默认分布，靠 Shuffle 加资源来扛。

第二类：小表。几百万行以内的表，Broadcast 的成本很低，而且 Broadcast 的适应性更强，不需要任何建表约束。给维表套上 Colocate 约束，收益有限，反而把它的分桶数锁死了——将来维表数据涨了十倍，你想改分桶数就要重建，得不偿失。

第三类：写入极其频繁且需要实时可见的表。Colocate 约束会增加 Tablet 调度和副本放置的复杂度，在主键模型高频写入的场景下，偶尔会出现副本修复滞后导致 Group 不稳定。如果业务对查询延迟不敏感，但绝对不能接受任何"状态不稳定"，那还是保守一些。

第四类：需要频繁扩缩容的集群。每次扩缩容之后，Group 都要重新达成"同序号桶同机"的一致状态，这个过程在数据量大的时候可能持续很久，期间 Colocate Join 会退化。如果集群规模经常变动，这个特性带来的收益会被不稳定的窗口吃掉一部分。

6. 线上巡检与容量变化时，这套机制要怎么维护

6.1 把 Group 状态纳入日常巡检的几个固定动作

Colocate Group 的状态不是建完就一劳永逸的，它依赖集群里 BE 的健康度、副本的完整性、均衡器的行为。我的做法是在日常巡检脚本里固定加三条检查，成本很低但能提前发现大部分问题。

第一条是每天扫一遍SHOW PROC '/colocation_group'，筛出IsStable = false的 Group 并告警。这条能覆盖绝大部分异常，比如某台 BE 短暂失联导致副本不完整、某次建表失败留下的残留。

第二条是对比 Group 的BucketsNum和成员表的实际分桶数。正常情况下这两者永远相等，如果不等，说明有一方的元数据出了问题，需要人工介入。

第三条是核对每个 Group 的成员表清单，和设计文档里的预期清单对一遍。这条听起来很土，但真的有用——经常有临时表、测试表被误加了colocate_with属性，悄悄混进 Group，然后它的分桶数一不一致，整个 Group 的状态就乱了。我曾经在一次排查中发现某个 Group 里混进了三张早已无人问津的中间表，其中一张的分桶算法还是旧版本默认值。

修复动作本身不复杂。如果只是副本不完整，等副本自动修复完成，状态会自己回到 true；如果是有表配置错了，用ALTER TABLE ... SET ("colocate_with" = "")把它踢出 Group，或者干脆删掉重建；如果是 Group 本身被卡在不可用状态，可以在确认所有成员表结构一致之后，通过元数据层面的操作重建 Group，但这个动作风险较高，一定要先在测试环境演练。

6.2 扩缩容时那些不会报错但会让你难受的细节

集群扩容后，新的 BE 节点数据是空的。均衡器会开始搬运数据，而 Colocate Group 的搬运受"同序号桶同机"约束，它需要成组地搬——不能只搬 A 表的 3 号桶而不搬 B 表的 3 号桶，否则约束就破坏了。这带来两个后果：一是搬运的粒度更大，单次数据迁移量可能比普通表大得多；二是搬运期间 Group 可能不稳定，查询会退化。

实操上的建议是：扩容后先观察SHOW PROC '/colocation_group'的状态变化，等所有 Group 都稳定下来再放量。如果业务不能等，可以临时把关键查询的 hint 改成SHUFFLE，用可控的性能损失换稳定性，等均衡完成再撤掉 hint。这个手法我在几次大促前的扩容里用过，比硬扛着让查询随机变慢要踏实。

缩容的风险更高。下线一个 BE 之前，必须确认它上面没有 Colocate Group 的桶，或者确认它的副本能在其它节点上完整重建。如果直接下线，Group 会因为副本缺失进入不稳定状态，而且在重建完成之前，所有依赖它的查询都拿不到本地 JOIN 的收益。我的习惯是在缩容前先查一遍SHOW PROC '/colocation_group/<GroupId>'，把涉及目标 BE 的桶列出来，心里有数之后再操作。

还有一个容易被忽视的点：临时分区和TRUNCATE对桶状态的影响。批量重灌数据时如果用了TRUNCATE PARTITION再 INSERT，桶的编号不会变，Group 的约束也不受影响，这一点是安全的。但如果用了"删表重建"的方式重灌，新表的分桶属性一旦和 Group 不一致，就会出问题。数据重灌的流程要写进规范里：先检查建表语句里的colocate_with、桶数、分桶算法、副本数四项是否和 Group 一致，再去执行。

我在实际维护这套机制几年下来，最大的体会是：Colocate Join 的收益非常确定，但它的运维成本不像表面上那么低——它把一个"运行时随机发生"的性能问题，转化成了"建表时一次性决策、运维期持续守护"的工程问题。如果你的数仓有稳定的、高频的、大表对大表的等值 JOIN，这个交换是划算的；如果 JOIN 形态一天三变，那还是把精力放在分区裁剪和物化视图上更实在。最后分享一个小技巧：新建 Group 的时候，先拿两张各一百万行的测试表把整条链路走通——建表、EXPLAIN看有没有EXCHANGE、SHOW PROC看IsStable——确认无误之后再上生产大表。这一步花不了半小时，但能挡掉绝大多数因为属性写错而导致的返工。