GBase 8a
适配迁移
文章

GBase 8a 字符集与排序规则迁移:校验项与执行顺序

发表于2026-06-03 10:11:1642次浏览16个评论

从 MySQL 或 Oracle 迁入 GBase 8a 时,字符集(CHARACTER SET)与排序规则(COLLATION)差异会导致三类生产问题:存储长度边界变化、等值/范围比较结果不一致、以及加载阶段编码解析失败。MPP 架构下,元数据由协调节点管理,各 DataNode 按统一 DDL 存储分片数据;迁移阶段若仅在应用侧改连接编码而未在库内对齐表结构,会出现「单节点查询正常、分布式 Join 结果异常」的隐蔽缺陷。本文给出迁移前的对照检查、执行顺序与验收 SQL 思路。具体语法与系统变量以现场版本文档为准。

一、概念与影响范围

对象 作用 迁移中需关注
CHARACTER SET 字符编码(如 utf8mb4) 字节长度上限、驱动与 gload 文件编码
COLLATION 比较与排序规则 WHERE/ORDER BY/GROUP BY 结果、唯一约束冲突
列类型 CHAR/VARCHAR 按字符或字节计长(依版本) 截断、插入失败、索引长度

在 8a 上,库、表、列可存在不同级别默认值(以版本支持为准)。迁移目标应是:业务库统一字符集、规则与源库语义等价或差异已文档化,避免混用多种 collation 的 Join 列。

二、迁移前对照清单

  1. 源库导出:记录各库、表、列的 CHARACTER SETCOLLATION;导出 DDL 样本(含索引、唯一键)。
  2. 应用连接:JDBC URL 中 characterEncodinguseUnicode 等参数与 gload 文件编码(UTF-8/GBK)一致。
  3. 长度边界:utf8mb4 下 VARCHAR(255) 的字节占用与源库是否一致;超长索引是否超过 8a 索引长度上限。
  4. 大小写与重音:ci(case insensitive)与 bin(binary)规则混用会导致 = Join 丢行或重复。
  5. 特殊字符:零宽字符、全角空格在源库可插入,目标库规则若不同,清洗策略需提前确定。

建议在隔离环境用 同一份抽样文件 执行 gload → 行数 checksum → 关键列 GROUP BY 对比,再进入生产割接。

三、推荐执行顺序

阶段 A:目标库默认值

在空库或维护窗口设置库级默认字符集与排序规则,使后续 CREATE TABLE 未显式指定时继承统一配置。修改库默认值 不自动 改写已有表,已存在表须单独处理。

阶段 B:表结构迁移

优先采用「导出 DDL → 在 8a 调整 CHARSET/COLLATE → 建表 → 导数」而非先建后改。原因:大表 ALTER CONVERT 在分布式环境可能长时间锁表并产生大量重写 IO。

对必须在线变更的表:

  1. 评估表规模、是否有长事务依赖。
  2. 在从库或低峰执行 ALTER,观察各 DN 磁盘与 redo。
  3. 变更后对该表执行 ANALYZE TABLE,避免统计信息陈旧导致计划异常(与性能专题衔接)。

阶段 C:数据加载

使用 gload 时显式指定文件字符集参数(名称以 gload 文档为准)。加载后抽样:

  • 中文、emoji、特殊符号列是否原样可读;
  • 行数与源端一致;
  • 最大长度字段无静默截断。

若出现乱码,优先排查 文件 BOM、终端编码、连接编码 三重一致性,再查表列字符集。

阶段 D:索引与约束重建

字符集变更可能导致唯一索引冲突模式变化(例如 ci 下视为相同的两行)。割接后运行:

  • 唯一键冲突检测脚本;
  • 核心业务 SELECT COUNT(DISTINCT key) 与源库对比(允许割接点差异)。

四、Join 与比较语义验证

迁移后必须通过 业务等价 SQL 验证,不能仅 SELECT 1

  1. 等值 Join:主键/编码列两侧 collation 一致;若一侧为 utf8mb4_general_ci、另一侧为 utf8mb4_bin,可能产生多余匹配或匹配失败。
  2. 范围过滤WHERE name > 'A' 在不同 collation 下边界字符集不同,报表合计可能偏移。
  3. ORDER BY:分页接口依赖排序稳定;规则变更会导致翻页重复或遗漏。
  4. GROUP BY:维表编码归并规则变化会影响汇总指标。

验证方法:选取 5–10 条生产典型 SQL,在源库与 8a 分别执行,对比结果集行数与合计值(在割接一致性窗口内)。

五、常见问题与处理

现象 可能原因 处理方向
插入报 Data too long 字节长度超限 扩大 VARCHAR 或改 utf8mb4 计算方式
唯一键冲突增多 ci 规则合并视为相同 清洗数据或改 bin 规则并评估业务
Join 行数变少 collation 不一致 统一列规则或 CAST 为同一 collation
gload 乱码 文件与参数编码不一致 统一 UTF-8 无 BOM 或指定 GBK
应用正常、批处理异常 批处理连接编码不同 统一连接池与脚本编码配置

六、MPP 相关说明

字符集为元数据属性,分布键、分区键仍为行列数据的逻辑划分。需注意:

  1. 各 DN 上同一分片表结构一致,由集群 DDL 同步;不存在「单节点 charset 不同」的合法状态。
  2. 涉及 REDISTRIBUTE 的 SQL 在比较阶段仍遵循列 collation;迁移后应用 EXPLAIN 对比核心 SQL,确认 Motion 未因类型转换隐式增加。
  3. 复制表(REPLICATED)维表编码错误会在所有节点同等放大,应在加载后立即做维表抽样。

七、回滚与变更记录

割接窗口内保留:

  • 变更前 DDL 导出;
  • 库级/表级 charset 配置截图或文本;
  • 抽样对比结果(行数、合计、DISTINCT 计数)。

回滚策略取决于是否已双向写入:仅只读割接可回退 DNS;双向同步场景需按变更表逐表评估,不能仅恢复连接参数。

八、验收检查项(发布前可打印)

  1. 库、表、列字符集与迁移方案文档一致。
  2. 应用与 gload 编码配置已纳入配置管理。
  3. 核心业务 SQL 结果集行数、合计与源库在约定窗口内一致。
  4. 唯一键、主键无新增冲突。
  5. 含 ORDER BY 分页的接口抽样无重复/遗漏页。
  6. 大表变更后已 ANALYZE,核心 SQL 计划无异常 Motion 增加。
  7. 监控无因截断导致的错误率上升。

小结

GBase 8a 字符集迁移的核心是 默认值、表 DDL、加载编码、比较规则 四级一致,并以业务 SQL 结果集作为最终验收依据。执行顺序建议:先统一库默认 → 建表时写清列级 CHARSET/COLLATE → gload 与连接编码对齐 → Join/排序/聚合抽样对比 → 必要时 ANALYZE 与计划复核。将差异项写入变更记录,明确是否接受 ci/bin 语义变化,避免仅完成「能插入中文」即视为迁移完成。

评论

登录后才可以发表评论
GBase用户47954发表于 3个月前
感谢作者的精彩分享!
GBase用户51966发表于 3个月前
总结得很到位,学习。
GBase用户50900发表于 3个月前
不错的文章,受益匪浅。
GBase用户51511发表于 3个月前
内容详实,值得收藏。
佛洛伊得发表于 3个月前
写得真不错,赞一个!
GBase用户51510发表于 3个月前
总结得很到位,学习。
塔山发表于 3个月前
写得真不错,赞一个!
一个老汉发表于 3个月前
感谢分享,非常有帮助。
GBase用户21182发表于 3个月前
优秀
GBase用户21182发表于 3个月前
点赞!
GBase用户21182发表于 3个月前
学到了。
GBase用户21182发表于 3个月前
多谢分享
GBase用户21182发表于 3个月前
作者辛苦啦
GBase用户51829发表于 2个月前
迁移需保证默认字符集、表结构、入库编码、排序规则一致
GBase用户51829发表于 2个月前
总结的很好,已经收藏
gbase0001发表于 2个月前
感谢分享,受益匪浅