mysql迁移至gaussdb前须做兼容性检查：禁用select…into outfile/load data、适配group by严格模式、替换不支持函数、规范字符集；dms迁移需配置binlog_row_image=full、连接参数及手动设位点；mysqldump需加--compatible=postgresql；验证须用pt-table-checksum、抽样比对和时区统一。
MySQL 迁移前必须做的兼容性检查
GaussDB(for MySQL) 虽宣称兼容 MySQL 5.7/8.0 协议，但实际存在大量语法、函数和行为差异，跳过评估直接迁移大概率导致应用报错或数据不一致。
重点检查以下几类内容：
-
SELECT ... INTO OUTFILE和LOAD DATA INFILE：GaussDB 不支持本地文件读写，需改用gs_dump/gs_restore或 DMS 工具 -
GROUP BY严格模式：MySQL 5.7 默认允许非聚合字段出现在SELECT列表中，GaussDB 默认启用sql_mode=ONLY_FULL_GROUP_BY，会直接报错 - 不支持的函数：如
SYSDATE()（需替换为NOW()），INSERT … ON DUPLICATE KEY UPDATE在部分 GaussDB 版本中对唯一索引判断逻辑不同 - 字符集隐式转换：MySQL 中
utf8mb4与utf8混用可能被容忍，GaussDB 对collation匹配更严格，建表语句若漏写COLLATE易引发排序异常
用 DMS 工具做全量+增量迁移的关键配置
DMS（Data Migration Service）是华为云官方推荐的在线迁移方案，但默认配置极易失败——尤其在开启增量同步时。
实操中必须调整以下参数：
- 源库需开启
binlog_row_image=FULL，否则 DMS 捕获不到完整变更字段，增量阶段会丢数据 - 目标库连接字符串中必须显式添加
?useSSL=false&allowPublicKeyRetrieval=true，否则 Java 驱动握手失败 - “对象迁移”页签里，勾选
迁移索引和迁移外键，但不要勾选迁移存储过程/函数（GaussDB 的 PL/pgSQL 兼容层不支持 MySQL 存储过程语法） - 增量同步起始位点不能依赖 DMS 自动获取：应先用
SHOW MASTER STATUS记下源库当前File和Position，在 DMS 任务中手动填入，避免从历史 binlog 开始拉取导致重复
mysqldump + gs_restore 迁移时的编码与权限陷阱
当无法使用 DMS（例如无公网或 VPC 网络不通），需走离线 dump 方式。但直接 mysqldump --databases db1 > a.sql 再导入 GaussDB 会失败。
核心问题在于导出格式与 GaussDB 解析器不匹配：
- 必须加
--compatible=postgresql参数（尽管目标不是 PostgreSQL），这是绕过 GaussDB 对 MySQL 扩展语法校验的唯一有效方式 - 导出时禁用
--hex-blob，否则 GaussDB 会把十六进制字符串误认为字面量而非 BLOB 数据 - 导入前需手动删除 dump 文件中的
CREATE DATABASE和USE语句——GaussDB 不支持跨库执行，且数据库需提前用CREATE DATABASE ... WITH ENCODING 'UTF8'创建好 - 用户权限要映射：MySQL 的
GRANT SELECT ON db1.* TO 'u1'需转为 GaussDB 的GRANT CONNECT ON DATABASE db1 TO u1; GRANT USAGE ON SCHEMA public TO u1; GRANT SELECT ON ALL TABLES IN SCHEMA public TO u1;
迁移后验证数据一致性的最小可行动作
别只查行数是否相等——GaussDB 和 MySQL 对 NULL、空字符串、时间戳微秒精度的处理有细微差别，肉眼难察觉。
建议按优先级执行三项检查：
- 用
pt-table-checksum（Percona Toolkit）对比主键表：它基于分块 CRC 校验，比全表COUNT(*)快且可靠；注意在 GaussDB 上需配合--chunk-index=PRIMARY指定主键索引，否则容易超时 - 抽样比对关键业务字段：比如订单表的
amount字段，执行SELECT id, ROUND(amount, 2) FROM orders ORDER BY id LIMIT 1000，两边结果逐行比对浮点精度截断是否一致 - 检查自增 ID 偏移：GaussDB 的
serial类型默认从 1 开始，若原 MySQL 表AUTO_INCREMENT=10000，需在 GaussDB 中执行ALTER SEQUENCE orders_id_seq RESTART WITH 10000，否则新插入记录 ID 会冲突
最常被忽略的是时区处理：MySQL 默认用系统时区，GaussDB 默认用 UTC。迁移后若未统一设置 timezone='Asia/Shanghai'，NOW() 返回值会差 8 小时，且已存的时间字段不会自动转换。
