GBase 8a 分布式 UPDATE/DELETE 实战：为何「改几行」也会拖垮集群

在单机 MySQL 里，UPDATE t SET status=1 WHERE id=100 往往毫秒级返回。迁到 GBase 8a MPP 后，同样写法可能跑几分钟、锁多表、甚至把 Coordinator 与多个 DataNode 的 IO 一起打满。根因通常不是「SQL 写得丑」，而是 8a 要在多节点上定位行、可能跨节点重分布、再逐分片提交——与只读查询的 EXPLAIN 优化路径不同，写操作还有事务与元数据开销。

本文从 MPP 写路径讲起，给出可落地的改写与运维策略，帮助 DBA 在批更、归档删除场景里少踩坑。

一、先建立预期：8a 上的写不是「点哪改哪」

GBase 8a 表按 HASH（或指定键）分布 到各 DataNode。执行 UPDATE/DELETE 时，协调节点（Coordinator）要：

1. 解析 WHERE，判断能否 分区裁剪 / 分布键裁剪，减少扫描分片数；
2. 在各 DN 上并行扫描命中的分片，必要时做 Motion（如 WHERE 条件不是分布键，却要按 Join 键更新关联表）；
3. 在分片内加锁、写 redo/日志，再由 CN 汇总结果。

因此下面三类写法在 8a 上风险最高：

接到「改数慢」工单时，先问：改的是哪张表、分布键是什么、WHERE 能否落到分片、是否批处理。

二、用 EXPLAIN 看写操作前的「读成本」

8a 对 UPDATE/DELETE 也会生成计划（版本与工具以现场为准）。在 gccli 里对「改前 SELECT」或 EXPLAIN UPDATE 做对比，重点仍看 Motion：

-- 先看「会改多少行」——务必带与 UPDATE 相同的 WHERE
EXPLAIN
SELECT COUNT(*)
FROM orders
WHERE dt = DATE '2026-05-01' AND status = 0;

-- 若业务允许，对比：WHERE 带分布键 vs 不带
EXPLAIN
SELECT COUNT(*)
FROM orders
WHERE user_id = 12345 AND status = 0;

阅读计划时建议标注：

• 是否全分片 Table Scan：未带分区键/分布键时，每个 DN 都要扫本地分片；
• 是否 REDISTRIBUTE：例如 UPDATE orders o JOIN users u ON o.user_id=u.id 且两侧分布键不一致，更新前要先对齐数据；
• 是否有 Gather 到 CN：极大数据量汇总时，CN 可能成为瓶颈。

若 COUNT 的 EXPLAIN 已是全分片扫描，直接执行 UPDATE 只会更慢——应先 缩 WHERE、改分布键设计或分批。

三、分布键与 WHERE：决定「改局部还是改全网」

事实表 orders 按 user_id HASH 分布时：

较优：WHERE user_id = ? AND order_id = ? —— 优化器可定位单 DN（或极少数 DN）分片，锁范围小。

较差：WHERE dt = '2026-05-01' 且表按 user_id 分布 —— 每个 DN 都要扫本地 dt 命中的行，相当于 并行全分片过滤，行数一大就慢。

改法路径（按优先级）：

1. 表设计：若业务以日期批更为主，评估 DISTRIBUTED BY 与 RANGE/LIST 分区 组合，让 dt 能裁剪分片（参见分区裁剪实践文）。
2. 改写为分批：按 user_id 范围或主键段循环，每批提交，控制单事务行数（如 5万～20万，按 redo 能力调）。
3. 中间表：INSERT INTO staging SELECT ...（分布键与目标表一致）再 UPDATE orders o JOIN staging s ON ...，让 Motion 只发生一次且可复用统计信息。

-- 分批示例（伪代码逻辑，批次大小按现场调）
-- 第 1 批：user_id BETWEEN 1 AND 50000
UPDATE orders
SET status = 1
WHERE user_id BETWEEN 1 AND 50000
  AND dt = DATE '2026-05-01'
  AND status = 0;
COMMIT;

四、DELETE 归档：别用一条 SQL 删光历史

历史数据归档常见 DELETE FROM orders WHERE dt < '2025-01-01'。在 MPP 上这会导致：

• 各 DN 长时间持有行锁与元数据锁；
• 大量 redo 与空间回收压力，影响同期查询；
• 若误不带分区键，还会拖慢整个集群。

推荐 分段删除 + 低峰执行：

-- 按天或按主键段删除，每段 COMMIT
DELETE FROM orders
WHERE dt = DATE '2025-12-31'
LIMIT 100000;
-- 重复执行直至影响行数为 0（语法 LIMIT 以版本文档为准）

更稳妥的归档路径：

1. 导出冷数据：gunload / 导出到对象存储；
2. 新建历史表或分区交换：将冷分区 DROP/EXCHANGE 下线，比逐行 DELETE 省 redo；
3. 必须 DELETE 时，用调度任务控制并发，并监控 dn 磁盘与 redo 使用率。

五、UPDATE 关联子查询：先减行再改

下列模式在业务里常见，但在 8a 上极易变成「大读 + 大写」：

UPDATE orders o
SET o.status = 2
WHERE o.order_id IN (
  SELECT order_id FROM refund_apply r WHERE r.batch_no = 'B20260530'
);

若 refund_apply 很小、orders 极大，且 order_id 不是 orders 的分布键，执行时往往要在各 DN 上反复匹配。改法：

1. 将子查询结果落入 临时表或 staging 表，分布键与 orders 对齐（如 order_id）；
2. 再 UPDATE orders o INNER JOIN staging s ON o.order_id = s.order_id SET ...；
3. 对 staging 做 ANALYZE，避免优化器低估行数。

六、事务、锁与止血

写操作变慢时，在 CN 上先看会话与锁，避免误杀只读查询：

SHOW PROCESSLIST;
-- 关注 Time 极大、State 为 Updating / Locked 的会话

-- 确认是否存在未提交的大事务（示例）
SELECT * FROM information_schema.innodb_trx
WHERE trx_started < NOW() - INTERVAL 10 MINUTE;

止血顺序建议：

1. 与业务确认能否 暂停批任务；
2. 对明确卡死的批更会话，按规范 KILL QUERY / KILL CONNECTION（先杀从库或大事务源）；
3. 调整调度：将 DELETE/UPDATE 拆到 维护窗口，并与加载任务错峰；
4. 根因修复：改分布键、加分区、改 staging 流程，而不是单纯加大 innodb_lock_wait_timeout 一类参数。

七、与批量加载的配合

若目标是「整表换数」或「大批量状态刷新」，很多时候 gload 重载分区 比 UPDATE 更快（需评估业务停机与双表切换）。典型流程：

1. 导出需保留的增量；
2. 按目标分布键 gload 到新表；
3. 校验行数与抽样 checksum；
4. 元数据切换表名或交换分区。

这比亿级 UPDATE 更贴合 8a 的并行写入模型。

小结

GBase 8a 的 UPDATE/DELETE 性能，取决于 WHERE 能否裁剪分片、分布键是否对齐、事务是否够小、是否在删除/归档时用对工具。排查时先用与 UPDATE 同条件的 EXPLAIN SELECT/COUNT 看是否全分片扫描与 REDISTRIBUTE；落地时优先分批、staging 表、分区归档与 gload 重载，避免在高峰用一条大 SQL 改全网。把「改前计划、批大小、耗时、redo 峰值」记入案例库，团队以后看到「改几行」的工单，会先问分布键而不是先加索引。