GBase 8a DDL 操作规范：ALTER TABLE、分布键变更与锁影响评估

在 GBase 8a MPP 集群中，DDL 语句（ALTER TABLE、CREATE INDEX、DROP COLUMN 等）的执行路径与单机实例不同：元数据变更由协调节点下发，各 DataNode 同步执行并返回确认；执行期间对目标表的读写请求根据操作类型和版本实现可能阻塞或需排队。误判 DDL 代价轻则锁住业务核心表数秒，重则在高并发场景下触发全集群锁链，引发连接积压。本文梳理常见 DDL 类型的执行特征、锁影响评估方法及可操作的执行策略。语法与锁行为以现场版本文档为准。

一、DDL 执行模型与锁影响边界

GBase 8a 的 DDL 执行分为两个阶段：

1. 元数据阶段：协调节点更新系统表（字典表）、持有 MDL（元数据锁），等待当前活跃事务释放目标表上的锁。
2. 数据阶段：各 DataNode 执行实际文件/结构变更，如列追加、索引构建、分片重建。

DDL 触发的锁类型与持有时间差异显著：

DDL 类型	常见锁级别	数据阶段代价	对并发 DML 的影响
ADD COLUMN（非默认值）	MDL 写锁短暂，快速完成	仅元数据	极短阻塞
ADD COLUMN（含默认值/NOT NULL）	MDL 写锁，需回写全表	各 DN 全表回写	中等阻塞，与表规模正相关
DROP COLUMN	MDL 写锁，列标记删除或重建	视实现而定	中到高
CHANGE/MODIFY COLUMN 类型	MDL 写锁，全表重建	各 DN 全量 IO	长时间阻塞
ADD INDEX	MDL 读锁（部分版本支持 Online）	全表扫描建索引	低到中
DROP INDEX	MDL 写锁短暂	仅元数据	极短
RENAME TABLE	MDL 写锁	仅元数据	极短
TRUNCATE TABLE	MDL 写锁	分片清空	短暂全表锁
ALTER DISTRIBUTED BY	MDL 写锁，全表重分布	全量 REDISTRIBUTE	长时间，表级锁

关键原则：任何需要全表扫描或全表重写的 DDL，代价与 DataNode 数量及单分片数据量线性相关，不可简单按单机经验估算。

二、执行前评估步骤

执行 DDL 前，建议完成以下检查：

1. 确认活跃事务与长查询

SHOW FULL PROCESSLIST;
SELECT * FROM information_schema.innodb_trx
ORDER BY trx_started ASC LIMIT 20;

DDL 在等待 MDL 时会阻塞后续所有该表的 DML。若当前存在长事务或执行时间超过 1 分钟的 SELECT，应在其完成后再执行 DDL，或协调业务窗口。

2. 估算数据量

-- 各节点分片行数（表名以实际为准）
SELECT COUNT(*) FROM target_table;

对于超过亿行的表，涉及全表重写的 DDL（列类型变更、分布键变更、含默认值的 ADD COLUMN）建议放入维护窗口，并预留完成时间的 2–3 倍作为窗口长度。

3. 磁盘空间评估

全表重建类 DDL 会在各 DN 上同时产生原表大小的临时空间（索引除外）。执行前需确认各节点 df -h 数据目录剩余空间 > 原表大小的 1.2 倍。

三、分布键变更（ALTER DISTRIBUTED BY）

分布键决定数据在各 DataNode 的分片逻辑，变更分布键等同于对全表数据做一次 全量 REDISTRIBUTE，代价极高：

• 各 DN 上全部行按新分布键重新哈希，写入新位置
• 执行期间目标表持有表级锁，所有 DML 阻塞
• 临时空间需求约为原表的 1 倍

标准操作流程（降低影响）：

1. 创建新表，指定新分布键 DDL；
2. 在维护窗口，INSERT INTO new_table SELECT * FROM old_table（分批或直接，视规模）；
3. 对 new_table 执行 ANALYZE TABLE；
4. 在业务低峰原子替换表名（RENAME TABLE old_table TO old_table_bak, new_table TO old_table）；
5. 验证业务功能与 SQL 计划后，保留备份表一段时间再删除。

直接 ALTER TABLE ... DISTRIBUTED BY 虽语法简洁，在大表生产环境上因锁持有时间过长，通常不如双表切换路径稳定。

四、索引变更

建索引

部分版本支持 Online DDL 方式建索引（允许并发 DML，以版本文档为准）。无论是否 Online，建索引都需要：

• 对全表做扫描，代价与数据量正相关；
• 在各 DN 并行构建，最终协调节点汇总元数据。

建索引前需评估：索引列选择性是否足够高（过低则索引无实际加速效果）；是否已有覆盖相同前缀的复合索引。避免无效索引占用存储和影响 DML 性能。

删索引

通常仅涉及元数据操作，对业务影响极短。删除前需确认无业务 SQL 依赖该索引（可用 EXPLAIN 验证删除后计划变化）。

五、列变更注意事项

ADD COLUMN 无默认值 vs 有默认值

• 无默认值（NULL 允许）：多数版本可快速完成，仅修改元数据，不回写历史行。
• 有默认值或 NOT NULL：需对历史行填充默认值，触发全表更新 IO。大表上建议先以 NULL 允许方式加列，应用分批 UPDATE 填充，再 ALTER COLUMN SET DEFAULT 或加 NOT NULL 约束。

MODIFY/CHANGE COLUMN 类型

类型变更（如 INT 改 BIGINT、VARCHAR(100) 改 VARCHAR(500)）通常触发全表重建。即便是简单扩容（VARCHAR 增长），在部分版本仍会引发数据页重写。执行前必须确认：

1. 变更后类型与旧数据完全兼容（无精度损失、无截断风险）；
2. 依赖该列的索引会自动重建还是需手动处理；
3. 应用层映射（JDBC 类型、ORM 字段）已同步更新。

六、执行与监控

DDL 执行期间，在另一个 gccli 会话中持续观察：

SHOW PROCESSLIST;
-- 关注 Command='ALTER TABLE' 对应行的 Time 字段与 State 变化
-- 关注是否有其他 Locked 状态堆积

各 DN 主机侧：

# 磁盘 IO 与空间
iostat -x 5
df -h

若 DDL 执行超出预期时间窗口，需评估是否终止（KILL QUERY ），并提前通知业务切换降级方案。已部分完成的 DDL 终止后，数据库通常可回滚元数据；但全表重建类操作中途终止，可能留下临时文件，需人工清理（以版本行为为准）。

七、回滚准备

每次生产 DDL 执行前，归档：

• 变更前完整 DDL（SHOW CREATE TABLE target_table）；
• 受影响索引列表；
• 关键 SQL 的 EXPLAIN 文本；
• 应用配置涉及列类型的 ORM 映射版本。

若业务验证不通过，按归档 DDL 执行逆向变更；注意逆向变更同样持有锁，同样需要窗口。

八、与运维专题的衔接

• 锁等待：DDL 等待 MDL 时会阻塞后续 DML，形成锁链；与锁等待专题中的 PROCESSLIST 排查步骤衔接，优先识别 MDL 等待来源。
• 统计信息：含全表重建的 DDL 完成后，统计信息自动失效概率较高；应在变更后、开放业务前执行 ANALYZE TABLE（与统计信息专题衔接）。
• 备份：大表结构变更前，建议确认最近一次备份有效，或在结构变更完成后立即触发一次增量备份。

小结

GBase 8a DDL 操作的核心风险点在于：MDL 等待与活跃事务的叠加、全表重建类 DDL 的临时空间与 IO 消耗、以及分布键变更引发的全量 REDISTRIBUTE。标准操作路径是：确认无长事务 → 估算数据量与磁盘余量 → 维护窗口执行 → PROCESSLIST 持续观察 → 变更后 ANALYZE → 回滚文档归档。分布键变更建议采用双表切换而非直接 ALTER，避免生产表持锁时间超出业务容忍范围。