GBase 8a 字符集与排序规则迁移:校验项与执行顺序
从 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 列。
二、迁移前对照清单
- 源库导出:记录各库、表、列的
CHARACTER SET、COLLATION;导出 DDL 样本(含索引、唯一键)。 - 应用连接:JDBC URL 中
characterEncoding、useUnicode等参数与 gload 文件编码(UTF-8/GBK)一致。 - 长度边界:utf8mb4 下 VARCHAR(255) 的字节占用与源库是否一致;超长索引是否超过 8a 索引长度上限。
- 大小写与重音:ci(case insensitive)与 bin(binary)规则混用会导致
=Join 丢行或重复。 - 特殊字符:零宽字符、全角空格在源库可插入,目标库规则若不同,清洗策略需提前确定。
建议在隔离环境用 同一份抽样文件 执行 gload → 行数 checksum → 关键列 GROUP BY 对比,再进入生产割接。
三、推荐执行顺序
阶段 A:目标库默认值
在空库或维护窗口设置库级默认字符集与排序规则,使后续 CREATE TABLE 未显式指定时继承统一配置。修改库默认值 不自动 改写已有表,已存在表须单独处理。
阶段 B:表结构迁移
优先采用「导出 DDL → 在 8a 调整 CHARSET/COLLATE → 建表 → 导数」而非先建后改。原因:大表 ALTER CONVERT 在分布式环境可能长时间锁表并产生大量重写 IO。
对必须在线变更的表:
- 评估表规模、是否有长事务依赖。
- 在从库或低峰执行
ALTER,观察各 DN 磁盘与 redo。 - 变更后对该表执行
ANALYZE TABLE,避免统计信息陈旧导致计划异常(与性能专题衔接)。
阶段 C:数据加载
使用 gload 时显式指定文件字符集参数(名称以 gload 文档为准)。加载后抽样:
- 中文、emoji、特殊符号列是否原样可读;
- 行数与源端一致;
- 最大长度字段无静默截断。
若出现乱码,优先排查 文件 BOM、终端编码、连接编码 三重一致性,再查表列字符集。
阶段 D:索引与约束重建
字符集变更可能导致唯一索引冲突模式变化(例如 ci 下视为相同的两行)。割接后运行:
- 唯一键冲突检测脚本;
- 核心业务
SELECT COUNT(DISTINCT key)与源库对比(允许割接点差异)。
四、Join 与比较语义验证
迁移后必须通过 业务等价 SQL 验证,不能仅 SELECT 1:
- 等值 Join:主键/编码列两侧 collation 一致;若一侧为
utf8mb4_general_ci、另一侧为utf8mb4_bin,可能产生多余匹配或匹配失败。 - 范围过滤:
WHERE name > 'A'在不同 collation 下边界字符集不同,报表合计可能偏移。 - ORDER BY:分页接口依赖排序稳定;规则变更会导致翻页重复或遗漏。
- GROUP BY:维表编码归并规则变化会影响汇总指标。
验证方法:选取 5–10 条生产典型 SQL,在源库与 8a 分别执行,对比结果集行数与合计值(在割接一致性窗口内)。
五、常见问题与处理
| 现象 | 可能原因 | 处理方向 |
|---|---|---|
| 插入报 Data too long | 字节长度超限 | 扩大 VARCHAR 或改 utf8mb4 计算方式 |
| 唯一键冲突增多 | ci 规则合并视为相同 | 清洗数据或改 bin 规则并评估业务 |
| Join 行数变少 | collation 不一致 | 统一列规则或 CAST 为同一 collation |
| gload 乱码 | 文件与参数编码不一致 | 统一 UTF-8 无 BOM 或指定 GBK |
| 应用正常、批处理异常 | 批处理连接编码不同 | 统一连接池与脚本编码配置 |
六、MPP 相关说明
字符集为元数据属性,分布键、分区键仍为行列数据的逻辑划分。需注意:
- 各 DN 上同一分片表结构一致,由集群 DDL 同步;不存在「单节点 charset 不同」的合法状态。
- 涉及
REDISTRIBUTE的 SQL 在比较阶段仍遵循列 collation;迁移后应用 EXPLAIN 对比核心 SQL,确认 Motion 未因类型转换隐式增加。 - 复制表(REPLICATED)维表编码错误会在所有节点同等放大,应在加载后立即做维表抽样。
七、回滚与变更记录
割接窗口内保留:
- 变更前 DDL 导出;
- 库级/表级 charset 配置截图或文本;
- 抽样对比结果(行数、合计、DISTINCT 计数)。
回滚策略取决于是否已双向写入:仅只读割接可回退 DNS;双向同步场景需按变更表逐表评估,不能仅恢复连接参数。
八、验收检查项(发布前可打印)
- 库、表、列字符集与迁移方案文档一致。
- 应用与 gload 编码配置已纳入配置管理。
- 核心业务 SQL 结果集行数、合计与源库在约定窗口内一致。
- 唯一键、主键无新增冲突。
- 含 ORDER BY 分页的接口抽样无重复/遗漏页。
- 大表变更后已
ANALYZE,核心 SQL 计划无异常 Motion 增加。 - 监控无因截断导致的错误率上升。
小结
GBase 8a 字符集迁移的核心是 默认值、表 DDL、加载编码、比较规则 四级一致,并以业务 SQL 结果集作为最终验收依据。执行顺序建议:先统一库默认 → 建表时写清列级 CHARSET/COLLATE → gload 与连接编码对齐 → Join/排序/聚合抽样对比 → 必要时 ANALYZE 与计划复核。将差异项写入变更记录,明确是否接受 ci/bin 语义变化,避免仅完成「能插入中文」即视为迁移完成。
评论
热门帖子
- 12025-12-01浏览数:183149
- 22023-05-09浏览数:25914
- 42023-09-25浏览数:19556
- 52020-05-11浏览数:18170