简介：本资源为瀚高数据库迁移工具 migration 4.1.4 版本，面向需要将 MySQL、Oracle 等多种数据库平滑迁移至瀚高数据库（HGDB）的 DBA、后端开发与信创改造项目人员。工具以图形化界面引导完成迁移全流程，涵盖新建迁移组、配置源库与目标库连接、创建迁移任务、选择库表、匹配数据类型等环节，并支持迁移进度展示与日志回溯，出错时可点击错误数字查看详情，便于快速定位问题。压缩包为 rar 格式，整体约 247.77MB，内含迁移工具主程序及配套使用说明文档，帮助读者理解各功能入口与操作要点。目前已有 1829 人学习下载，适合正在推进数据库国产化替代、需要验证迁移可行性与数据类型映射（如 datetime 转 TIMESTAMP）的技术人员参考实践。
1. 异构数据库迁移的最后一公里：为什么我盯上了瀚高 migration 工具
上周帮一家做供应链的客户做国产化替换，源库是 MySQL 5.7，目标库是瀚高数据库。表结构、索引、注释、自增主键、存储过程，光靠手写 DDL 改语法，一个下午只啃下来三张表，还漏了两个AUTO_INCREMENT的边界。后来翻到瀚高官方出的 migration 工具，专门干异构库往瀚高搬这件事，支持 MySQL、Oracle 等源端。它解决的不是「能不能连上」的问题，而是把类型映射、对象依赖顺序、数据分批搬运这些脏活打包成可配置流程。适合正在做信创替换、又不想把迁移写成一次性脚本的 DBA 和后端。这篇就把我拆包、试跑、踩坑的过程摊开讲，参数怎么设、哪一步最容易翻车，都写清楚。
2. 拆开 migration 工具：它到底搬了哪些对象
2.1 迁移范围与对象依赖顺序
先明确一件事：异构迁移最怕的不是数据量大，而是对象之间有依赖。视图依赖表，外键依赖主键，存储过程依赖表结构。migration 工具内部维护了一张对象优先级表，常见做法是按「表结构 → 主键/唯一约束 → 数据 → 索引 → 外键 → 视图 → 函数/存储过程 → 触发器」的顺序推进。这个顺序不是随便定的，外键如果先于数据建立，批量插入时每行都要校验，速度会掉一个数量级；索引如果在数据之前建，插入过程要不断维护 B 树，同样拖慢。
我一般会先跑一次「仅结构」的迁移，把 DDL 落到瀚高，确认类型映射没问题，再单独跑数据。工具里对应的是分阶段开关，别一上来就全量一把梭。下面是一个典型的配置片段，展示阶段控制：
# migration 工具分阶段执行示例（示意配置） migration \ --source-type mysql \ --source-host 10.0.0.21 \ --source-port 3306 \ --source-db supply_chain \ --source-user mig_user \ --source-password '***' \ --target-host 10.0.0.30 \ --target-port 5866 \ --target-db supply_chain_hg \ --target-user hg_user \ --target-password '***' \ --stage schema # 只迁结构，先验证类型映射--stage是关键参数，可选schema、data、index、all。先跑schema，用瀚高的客户端连上去\d+ 表名看字段类型对不对。--source-type决定用哪套类型映射规则，MySQL 和 Oracle 的映射表是分开的，别填错。
2.2 类型映射：MySQL 与 Oracle 的差异处理
类型映射是异构迁移的玄学重灾区。MySQL 的TINYINT(1)很多人当布尔用，但瀚高里没有TINYINT，工具默认映射成SMALLINT，如果你业务里靠 0/1 判断，逻辑不变；但如果源端真是布尔语义，最好手动改成BOOLEAN。Oracle 那边NUMBER(1)同理。还有DATETIME和TIMESTAMP的精度问题，MySQL 的DATETIME不带时区，Oracle 的DATE带时分秒但不带小数秒，瀚高对应的是TIMESTAMP系列。
我整理了一张常见映射对照，实际跑之前对着源库information_schema.columns过一遍：
| 源类型（MySQL） | 源类型（Oracle） | 瀚高目标类型 | 注意点 |
|---|---|---|---|
| TINYINT | NUMBER(3) | SMALLINT | 布尔语义需手动改 BOOLEAN |
| INT UNSIGNED | NUMBER(10) | INTEGER | 无符号范围可能溢出 |
| DATETIME | DATE | TIMESTAMP | 小数秒精度默认截断 |
| TEXT | CLOB | TEXT | 大对象分批读取 |
| VARCHAR | VARCHAR2 | VARCHAR | 长度按字符计，注意中文 |
工具允许通过--type-override传一个映射文件，格式是源类型=目标类型，一行一条。遇到UNSIGNED溢出的情况，我会把INT UNSIGNED强制映射成BIGINT，宁可多占点空间，也别在插入时报 out of range。
2.3 数据搬运的分批与断点
数据阶段最怕两件事：大表一次性拉爆内存，以及中途失败从头再来。migration 工具默认按行数分批，--batch-size控制每批提交量，我一般设 5000 到 10000。太小了网络往返多，太大了事务日志膨胀。配合--commit-interval控制提交频率，这两个参数要一起调。
断点续传靠的是工具内部记录已迁移的偏移量，通常落在一张元数据表里。如果你手动 kill 了进程，重新跑--stage data时它会问你是继续还是重来。这里有个血泪经验：如果源库在迁移期间还在写入，断点续传可能丢数据或重复，最好在业务低峰期做，或者先锁表。下面是一个带断点参数的命令：
# 数据阶段：分批 + 断点续传 migration \ --stage data \ --batch-size 8000 \ --commit-interval 5 \ --resume-from-checkpoint \ --checkpoint-table migration_ckpt--resume-from-checkpoint开启后，工具会读migration_ckpt表里的最后偏移。--checkpoint-table可以自定义名字，多套迁移任务共用一个库时，建议每套任务单独一张，避免互相覆盖。
3. 从 MySQL 到瀚高：一次完整迁移的实操步骤
3.1 环境准备与连接串配置
动手之前先把两边环境对齐。瀚高这边要确认端口，默认是 5866，不是 MySQL 的 3306，也不是 Oracle 的 1521。字符集建议统一成 UTF8，源库如果是latin1，迁移前先在源端做一次转码，别指望工具帮你猜。网络方面，migration 工具一般跑在能同时访问源库和目标库的中间机器上，别在源库本机跑，避免占满 IO。
连接串配置我习惯写成一个.env文件，避免命令行里暴露密码：
# migration.env SRC_TYPE=mysql SRC_HOST=10.0.0.21 SRC_PORT=3306 SRC_DB=supply_chain SRC_USER=mig_user SRC_PASS=your_password TGT_HOST=10.0.0.30 TGT_PORT=5866 TGT_DB=supply_chain_hg TGT_USER=hg_user TGT_PASS=your_password工具启动时用--env-file migration.env加载。注意瀚高的hg_user要有建表、建索引、写数据的权限，别用只读账号，否则跑到一半报权限错误，前功尽弃。
3.2 结构迁移与人工校验
结构迁移跑完后，别急着跑数据。我一般会做三件事：一是对比表数量，SELECT count(*) FROM information_schema.tables WHERE table_schema='supply_chain_hg'和源库对；二是抽查字段类型，重点看TINYINT、DATETIME、TEXT这几类；三是看注释有没有丢，瀚高支持COMMENT ON，但工具不一定全搬。
校验可以用一段 SQL 生成对比清单：
-- 在瀚高侧查字段类型，和源库人工比对 SELECT table_name, column_name, data_type, character_maximum_length FROM information_schema.columns WHERE table_schema = 'supply_chain_hg' ORDER BY table_name, ordinal_position;如果发现某张表字段类型不对，别直接改目标库，改映射文件重新跑这张表的结构。工具支持--table参数只迁指定表，避免全量重来。
3.3 数据迁移与一致性验证
数据跑完后，一致性验证是必须的。行数对不上是小事，金额、状态这类关键字段对不上才是大事。我一般会抽几张核心表做 checksum，比如SELECT md5(string_agg(...))这种，但异构库函数不一样，更稳妥的做法是抽主键范围，两边分别count和sum关键列。
-- 源库 MySQL：统计订单表金额 SELECT COUNT(*), SUM(amount) FROM orders WHERE created_at >= '2024-01-01'; -- 目标库瀚高：同样口径 SELECT COUNT(*), SUM(amount) FROM orders WHERE created_at >= '2024-01-01';两个结果一致，基本可以认为数据没丢。如果SUM有小数差异，检查DECIMAL精度映射，MySQL 的DECIMAL(10,2)到瀚高一般没问题，但FLOAT会有精度损失，关键金额字段建议在源端就改成DECIMAL。
4. 避坑与排查：迁移路上最容易翻车的五件事
4.1 自增主键序列不同步
现象：数据迁完后，应用插入新记录报主键冲突。原因：MySQL 的AUTO_INCREMENT迁到瀚高后变成序列，但序列当前值还是初始值，没跟上已有数据的最大 ID。解决：迁移后手动执行SELECT setval('表名_id_seq', (SELECT MAX(id) FROM 表名));，每张有自增的表都要做一遍。工具如果有--reset-sequence参数，记得打开。
4.2 字符集与排序规则不一致
现象：中文乱码，或者ORDER BY结果和源库不一样。原因：源库utf8mb4迁到瀚高UTF8，排序规则从utf8mb4_general_ci变成默认的C或zh_CN，大小写敏感性和排序顺序都变了。解决：建库时指定LC_COLLATE和LC_CTYPE，迁移前确认两边排序规则，必要时在查询里显式COLLATE。
4.3 大字段迁移超时
现象：TEXT或BLOB字段多的表，迁移到一半连接断开。原因：单批数据量太大，网络传输超时，或者目标库wal日志写满。解决：把--batch-size调小到 1000 以下，大字段单独用--table迁，避开高峰期。瀚高这边检查max_wal_size，必要时临时调大。
4.4 外键约束导致插入失败
现象：数据阶段报外键约束违反。原因：对象顺序没排对，子表数据先于父表插入。解决：数据阶段先禁用外键，迁完再启用。瀚高里可以ALTER TABLE 子表 DISABLE TRIGGER ALL;，迁完ENABLE。或者用工具的--defer-constraints参数。
4.5 存储过程语法不兼容
现象：结构迁移时存储过程报错，或者迁过去后调用失败。原因：MySQL 的DELIMITER、Oracle 的PL/SQL和瀚高的PL/pgSQL语法差异大，工具只能做基础转换。解决：存储过程建议人工重写，别指望工具全自动。先把源端逻辑导出来，对照瀚高文档改，改完在测试库跑一遍。
5. 进阶技巧：把迁移做成可重复的流水线
迁移不是一次性的活，尤其是做信创替换，往往要跑好几轮：测试环境一轮、预生产一轮、生产一轮。每轮都手动敲命令，迟早出错。我的习惯是把 migration 工具包进一个 shell 脚本，参数从环境变量读，跑完自动做一致性校验，校验不过就退出非零码，让 CI 拦住。
#!/bin/bash set -euo pipefail # 加载环境变量 source ./migration.env # 阶段一：结构 migration --env-file migration.env --stage schema # 阶段二：数据 migration --env-file migration.env --stage data --batch-size 8000 --resume-from-checkpoint # 阶段三：索引和外键 migration --env-file migration.env --stage index # 一致性校验：行数对比 SRC_COUNT=$(mysql -h$SRC_HOST -P$SRC_PORT -u$SRC_USER -p$SRC_PASS -N -e "SELECT COUNT(*) FROM $SRC_DB.orders") TGT_COUNT=$(psql -h$TGT_HOST -p$TGT_PORT -U$TGT_USER -d$TGT_DB -t -c "SELECT COUNT(*) FROM orders") if [ "$SRC_COUNT" != "$TGT_COUNT" ]; then echo "行数不一致：源 $SRC_COUNT，目标 $TGT_COUNT" exit 1 fi echo "迁移完成，行数校验通过"这个脚本里set -euo pipefail保证任何一步失败就停，不会带着错误往下跑。--resume-from-checkpoint让重跑时不用从头来。校验部分只对比了行数，实际生产里我会再加关键列的SUM和MAX，三重校验都过才算完。
还有一个技巧是「影子表」对比：在瀚高侧建一张和源表结构一样的影子表，迁移时同时写入，跑一段时间后对比两边数据差异。这招适合不能停机的场景，但配置复杂，一般项目用不上。
从那以后我每次做异构迁移，都强制先跑一遍--stage schema，人工核对字段类型，再跑数据，最后做三重校验。这个顺序帮我挡掉了至少三次主键冲突和两次金额精度丢失。希望帮到你。
本文还有配套的精品资源，点击获取
解法)