接到MySQL迁移到达梦的任务，你的第一反应如果是想“找个工具直接导”，那大概率后面还有好几轮加班等着。数据库迁移这件事，真正花时间的地方从来不是“搬数据”的动作，而是搬之前能不能看清风险、搬完之后能不能证明两边数据真的等价。我最近在处理一个内部业务系统的迁移，源库是MySQL 5.7，目标库是达梦8，整个排期三周，真正执行全量迁移只花了两天，剩下时间全在摸底、改对象脚本和做验证。这篇就把整套打法拆开来讲：从迁移前要拉出来的清单，到工具怎么搭配，到大表提速的实操参数，再到达梦和MySQL在类型与SQL方言上的差异，全程按我实际跑过的流程来。
1. 迁移前先做“技术摸底”：这三个清单必须拉出来
很多人拿到迁移任务就直接开始建目标库，这是最危险的开局。我习惯的做法是先花一两天做技术摸底，不是看文档，而是直接去源库里“体检”。这就像搬家前先把家具拍照贴标签，搬家公司来了才知道哪些要拆、哪些要包、哪些要扔。MySQL迁移到达梦的最大风险不是数据量，而是源库里那些“MySQL专属写法”在目标库上根本不认。
1.1 实例、库表、对象规模盘点
第一份清单是规模盘点，三个维度：实例维度、对象维度、数据维度。
实例维度要记录MySQL版本、字符集、lower_case_table_names的配置值。版本影响语法差异，字符集影响目标库建实例时的参数，大小写配置直接关系到后面对表名引号的处置。对象维度要统计每个库下有多少张表、视图、存储过程、函数、触发器、事件和序列。数据维度要看总行数、TOP大表、表空间大小。
我通常直接用information_schema拉统计，比如先看每个库的表数量和体积：
SELECT table_schema AS db, COUNT(*) AS table_cnt, ROUND(SUM(data_length + index_length) / 1024 / 1024, 2) AS size_mb FROM information_schema.tables GROUP BY table_schema;再用一条正则扫描把高危对象筛出来：
SELECT routine_type, routine_name FROM information_schema.routines WHERE routine_definition REGEXP 'GROUP_CONCAT|DATE_FORMAT|IFNULL|LIMIT|ON DUPLICATE KEY UPDATE|REPLACE INTO|FIND_IN_SET';这一步的价值是提前量化改造工作量。如果扫描出来几十个存储过程都用了GROUP_CONCAT，迁移计划里就要预留专门的改写时间，而不是等到DTS工具跑完才发现。
1.2 千万别漏掉的“MySQL专属写法”风险清单
摸底时我会重点标记下面这几类，它们几乎贯穿整个迁移过程：
AUTO_INCREMENT自增列。MySQL里习以为常，达梦对应的是IDENTITY，迁移工具通常能转，但自增起始值经常丢，后续要手工对齐。ON UPDATE CURRENT_TIMESTAMP。MySQL一条建表语句搞定，达梦没有等价语义，要么用触发器模拟，要么从应用层维护更新时间。GROUP_CONCAT、DATE_FORMAT、IFNULL、FIND_IN_SET、REGEXP这一批函数。达梦在MySQL兼容模式下部分能用，但更多时候要换成LISTAGG、TO_CHAR、NVL等写法。ENUM、SET、JSON类型。达梦没有和MySQL完全一一对应的类型，需要评估后映射成VARCHAR加CHECK约束，或者CLOB加函数处理。- 无符号整型。MySQL支持
UNSIGNED INT，达梦没有对应的无符号概念，数值一旦超过21亿，普通INT会直接溢出。 - 事件调度器（EVENT）。如果业务依赖MySQL定时事件，目标端需要用达梦作业或系统包重建。
- 表名大小写与引号行为。这属于最隐蔽的坑，后面我会专门说。
1.3 目标库的兼容模式：建实例前就得想清楚
达梦数据库在初始化实例阶段就支持选择兼容模式，比如更接近Oracle的写法，或者更接近MySQL的写法。这个决定非常关键，因为建好实例之后很多行为就很难再改。我建议在测试环境直接初始化一个MySQL兼容模式的实例，用源库的真实表结构和典型SQL跑一遍，验证哪些语法不用改就能用、哪些必须改。
另外，目标库的页大小和字符集最好一开始就定下来。页大小会影响单行最大长度，字符集影响字符串比较行为，中途改实例参数相当折腾。达梦默认端口是5236，初始化实例时还会生成SYSDBA用户的密码，这些信息记到迁移任务文档里，后面连接工具要反复用。
2. 迁移工具链怎么搭：图形工具负责搬运，脚本负责精修
我把迁移工具链分成两半：图形化迁移工具负责“搬运基础结构和数据”，手工脚本负责“精修业务逻辑”。不要指望任何单一工具能全自动搞定MySQL迁移到达梦，尤其是存储过程和定时任务这类对象。
2.1 达梦自带迁移工具的优势边界
达梦自带的图形化迁移工具（安装目录下通常叫DTS或类似名称）能直连MySQL，读取表结构、做字段类型映射、生成目标表结构，然后同步搬数据。对普通表和视图来说，这套流程很成熟，成功率也高。它能处理大量常规字段的映射，比如INT到INT、VARCHAR到VARCHAR、DATETIME到TIMESTAMP。
但它的能力边界也很明确：
- 存储过程和函数迁移出来后，经常需要手工调整语法细节。
- 触发器迁移依赖
DELIMITER、NEW/OLD等语义，工具容易生成半成品。 - MySQL的EVENT定时任务，工具基本不处理，需要在达梦上重建作业。
- 复合分区表在两个库上的默认行为差异大，必须逐个确认。
所以我的原则是：工具负责表、视图、数据这三件事，其余对象全部进入手工通道。
2.2 连接、权限、驱动等前置环境细节
迁移前先把连接链路准备好，别等工具启动才发现网络不通。
MySQL侧建议开一个独立迁移账号，权限包含SELECT、SHOW VIEW、EVENT、PROCESS即可，不建议直接用root。达梦目标侧给迁移账号分配DBA权限也行，但属于临时授权，迁移收尾后记得收回。
网络方面，如果数据量在百GB级别，源库和目标库最好在同机房内网，否则受带宽限制，迁移时间会成倍拉长。磁盘空间按源库实际占用（data_length + index_length）的1.5倍预留，因为目标端要同时承受数据文件、归档日志、临时排序空间和索引重建的资源开销。
2.3 哪些对象必须走“手工脚本”通道
手工通道的第一步是把MySQL侧对象定义导出到一个文本文件：
mysqldump -umigrate -p --no-data --routines --triggers --events source_db > schema_objects.sql第二步是在这个文件里批量搜索上一章提到的高危关键词，逐段做替换。第三步是按依赖顺序在达梦上执行：先表结构，再视图，再函数和存储过程，最后触发器。这个顺序不能乱，因为视图依赖表结构，触发器依赖表和存储过程，反着建必然报错。
手工处理尽量在测试环境先跑通一遍，不要直接在生产目标库上改。我一般是先导到测试实例，循环“报错、修改、再执行”，直到对象全部创建成功，再把最终版脚本拿到正式环境执行。
3. 全量迁移的实操过程：从创建目标库到数据落地
准备工作和对象脚本就绪之后，才进入真正的全量迁移。这一章按我实际操作时的顺序来写，每一步都尽量给出可直接套用的做法。
3.1 目标表空间、用户和权限的准备
在达梦上先建业务表空间，再建用户，并把默认表空间指过去：
CREATE TABLESPACE APP_DATA DATAFILE '/dm8/data/DAMENG/APP_DATA01.DBF' SIZE 2048M AUTOEXTEND ON NEXT 128M MAXSIZE 32G; CREATE USER APP IDENTIFIED BY "YourStrongPassword" DEFAULT TABLESPACE APP_DATA; GRANT DBA TO APP;这里的DBA权限是迁移期间临时使用的，等所有对象迁移完、数据校验通过后，要按最小权限原则回收并重新授权。不要因为图省事就长期保留DBA权限，尤其是线上环境。
达梦的表空间路径、数据文件写法在不同版本上略有差异，执行前以你手上版本的官方手册为准。我习惯把建库建用户脚本单独存一份，方便后面环境重建时复用。
3.2 表结构迁移与自增列的处理
在图形化迁移工具里选择源库和目标库后，会进入对象映射界面。这里要逐个确认：
- VARCHAR长度是否完整保留，超长文本是否被正确映射为CLOB或TEXT。
- DATETIME是否映射为TIMESTAMP，秒后小数精度是否一致。
- 自增列是否被正确识别为
IDENTITY。
关于自增列起始值，这是高频翻车点。MySQL侧可以用下面这条查询把每张表的当前自增值拉出来：
SELECT table_name, auto_increment FROM information_schema.tables WHERE table_schema = '你的业务库' AND auto_increment IS NOT NULL;迁移工具生成达梦IDENTITY列时，起始值经常不按源库对齐。如果业务里主键是自增的，迁移后新插入的数据就可能撞到旧数据的主键范围，导致主键冲突。我处理这种问题时，最稳妥的方法是先把自增列在目标表里建成普通INT，等数据搬迁完成后，再手工重建为IDENTITY并指定起始值。虽然多一步，但可控性最高。
3.3 大批量数据迁移的提速技巧
数据量大时，默认参数直接跑会慢得让人怀疑人生。以下几个调整项我每次都会检查：
- 提交批次。迁移工具的commit batch设置在1000到10000之间。单行记录较小（1KB以内）的表，批次可以取5000或更高；行宽、含CLOB字段的表批次要降到1000，否则事务提交本身会拖慢速度。
- 索引后置。大表优先搬数据，搬完再建索引。如果边导数据边建索引，每次插入都要维护B+树，代价高出一大截。
- 约束后置。外键、唯一约束在数据校验阶段之前先不启用，等数据正确性确认后再逐个开启。
- 并行任务。根据目标库CPU核数配置并行度，常见是4到8路。并行不是越大越好，资源争抢严重时反而会触发锁等待和IO瓶颈。
- 大表分片重试。如果表特别大，工具跑到一半中断，从断点续传并不总可靠。我习惯按主键范围把大表切段迁移，每段单独校验，即使某一段失败，也只重跑那一段。
3.4 视图、存储过程、触发器的手工改写流程
视图的改写相对简单。MySQL导出文件里常见的头部是CREATE ALGORITHM=UNDEFINED DEFINER=... SQL SECURITY DEFINER VIEW ...，这些前缀达梦不认，直接改成：
CREATE OR REPLACE VIEW view_name AS SELECT ...;存储过程的工作量大一些。MySQL的存储过程用DECLARE声明变量、用CONTINUE HANDLER处理异常，达梦更接近Oracle风格，异常处理要改成EXCEPTION WHEN OTHERS THEN的形式。循环语法也是差异点，MySQL的WHILE...DO...END WHILE和达梦的LOOP...END LOOP并不总是能无缝替换，碰到一个改一个，在测试环境验证到位才能拿到生产执行。
触发器改写时，MySQL的FOR EACH ROW是显式声明的，达梦里行级触发是默认行为；DELIMITER这种客户端分隔符要去掉，BEGIN...END块内的NEW和OLD引用可以保留。改完后记得建一批造数脚本，实际触发一次，确认行为一致。
4. 最容易翻车的三块：类型映射、SQL函数、SQL方言
全量迁移做完只是起点，业务起来后真正让人头疼的是SQL层面不兼容。这一章我按“类型—函数—方言”三个维度整理了一份常用对照，都是项目里实际碰到过的。
4.1 数据类型映射表与无符号整数、ENUM、JSON的处理
先给一张常用映射参考表：
| MySQL | 达梦(DM8) | 注意事项 |
|---|---|---|
| INT / INTEGER | INT | 常规情况 |
| TINYINT | SMALLINT / TINYINT | 布尔场景注意应用取值 |
| BIGINT | BIGINT | 常规情况 |
| UNSIGNED INT | BIGINT / NUMERIC(10,0) | 避免超过21亿溢出 |
| DECIMAL(M,N) | DECIMAL(M,N) | 注意精度和小数位 |
| VARCHAR(N) | VARCHAR(N) | 关注行长度上限 |
| TEXT / MEDIUMTEXT | TEXT / CLOB | 大字段查询行为验证 |
| BLOB | BLOB | 常规情况 |
| DATETIME | TIMESTAMP / DATETIME | 秒后精度要统一 |
| ENUM | VARCHAR + CHECK约束 | 或转关联表，先评估业务 |
| SET | VARCHAR / 关联表 | 位操作逻辑要重写 |
| JSON | JSON类型或CLOB | 新版本可达梦JSON；老版本用CLOB+函数模拟 |
ENUM和SET是我最想提醒的两类。MySQL里用起来很顺手，但达梦没有同构类型。临时方案是映射成VARCHAR并加CHECK约束，但如果代码里有ENUM('A','B')和索引值之间的运算，改造量就大了。另一个典型是无符号整型，源库为了省空间用UNSIGNED INT存IP转换后的整数或ID，目标库没有无符号概念，必须升级为BIGINT，否则数据跑到阈值就直接溢出报错。
JSON类型要看达梦版本。新版本支持JSON类型，老版本通常需要落成CLOB，再用字符串函数解析。迁移前先盘点应用里用了哪些JSON运算符，比如JSON_EXTRACT、->>这类，确认目标库对应能力后再决定映射方案。
4.2 常用MySQL函数替换为达梦写法
函数替换是SQL改写里最零碎、但最常见的工作。整理成表直接对照：
| MySQL | 达梦推荐写法 | 备注 |
|---|---|---|
| IFNULL(a, b) | NVL(a, b) 或 COALESCE(a, b) | 常规替换 |
| GROUP_CONCAT(col) | LISTAGG(col, ',') | 注意排序语义 |
| DATE_FORMAT(now(), '%Y-%m-%d') | TO_CHAR(SYSDATE, 'YYYY-MM-DD') | 格式符完全不同 |
| STR_TO_DATE(str, fmt) | TO_DATE(str, 'YYYY-MM-DD') | 注意格式符 |
| NOW() | SYSDATE / CURRENT_TIMESTAMP | MySQL兼容模式下可用 |
| CONCAT_WS | 用 || 拼接或嵌套CONCAT | 谨慎测试 |
| FIND_IN_SET(str, list) | 用INSTR或正则改写 | 业务语义要重写 |
| REGEXP | REGEXP_LIKE / 正则函数 | 语法有些差异 |
| LIMIT m, n | 兼容模式下可用LIMIT；其余用ROWNUM改写 | 老版本建议改写 |
分页查询是典型的方言差异。MySQL写LIMIT 20, 10，在达梦MySQL兼容模式下可以直接用，但如果实例没走MySQL兼容模式，就需要用ROWNUM改写成三层嵌套：
-- MySQL写法 SELECT * FROM orders ORDER BY id LIMIT 20, 10; -- 达梦非MySQL兼容模式下的常见改写 SELECT * FROM ( SELECT t.*, ROWNUM AS rn FROM ( SELECT * FROM orders ORDER BY id ) t WHERE ROWNUM <= 30 ) WHERE rn > 20;这类改写要留意执行计划的分页性能，尤其是前期数据量不大看不出来、数据一多就暴露问题。
4.3 存储过程和“易碎SQL”的改写思路
存储过程不是逐函数替换，而是整套语法风格的对齐。MySQL里常见的INSERT ... ON DUPLICATE KEY UPDATE，达梦没有等价语句，要改成MERGE INTO：
-- MySQL INSERT INTO t (id, name) VALUES (1, 'x') ON DUPLICATE KEY UPDATE name = 'x'; -- 达梦改写 MERGE INTO t USING (SELECT 1 AS id, 'x' AS name FROM DUAL) src ON (t.id = src.id) WHEN MATCHED THEN UPDATE SET t.name = src.name WHEN NOT MATCHED THEN INSERT (id, name) VALUES (src.id, src.name);REPLACE INTO同理，本质是“先删后插”，用MERGE INTO更稳妥。INSERT IGNORE这类写法也要改写成WHERE NOT EXISTS或MERGE，避免数据冲突时行为不一致。
还有一类容易被忽略的是批量插入。MySQL的JDBC批量插入可以通过rewriteBatchedStatements优化，达梦侧要确认驱动对批量提交的支持方式。如果直接把带ON DUPLICATE KEY UPDATE的大批量INSERT扔过去，大概率会报语法错误。
4.4 字符集、排序规则和大小写敏感的连锁反应
字符集这块，MySQL常用utf8mb4，达梦侧通常配置UTF-8，基本能对上。真正的问题在于排序规则差异和大小写敏感。
MySQL默认排序规则在很多环境下是大小写不敏感的，比如utf8mb4_general_ci，查询时WHERE name = 'abc'能匹配到ABC。达梦默认的实例行为是大小写敏感的，字符串比较结果可能和源库不一致。这会导致两个后果：一是应用层数据处理行为变化，二是索引失效，因为查询条件写法和列数据的大小写分布不再匹配优化器预期。
大小写问题还会影响表名和字段名的解析。达梦默认情况下，不带引号的表名会被统一转为大写存储。如果源库的表名是user_order，应用层SQL写SELECT * FROM user_order，达梦内部会找USER_ORDER，如果没有正确映射，就会报“表或视图不存在”。
针对这个问题，我建议在初始化达梦实例时就选好大小写策略。如果应用层SQL大量使用小写且不带引号，考虑实例初始化为大小写不敏感模式，能省掉后续大量改SQL的麻烦；反之，如果应用层SQL风格统一且ORM配置完善，走默认模式也可以，但对象名必须和工具生成的DDL严格对齐。这个决策要在建实例前做，不要等表建完再纠结。
5. 迁移完成不等于结束：验证、回归与切库
数据搬完、对象建好了，很多人宣布“迁移完成”，但真正的验收才刚开始。部署一个达梦环境很容易，证明它和MySQL在业务语义上等价很难。我的验证流程分三层：数据一致性、性能回归、应用切流。
5.1 数据一致性校验的具体做法
第一层是表数量和行数校验。用脚本遍历源库所有表，记录每个表的COUNT(*)，再到达梦上逐表比对：
mysql -umigrate -p -N -e "SELECT CONCAT(table_schema,'.',table_name) FROM information_schema.tables WHERE table_schema='业务库'" | while read t; do cnt=$(mysql -umigrate -p -N -e "SELECT COUNT(*) FROM $t") echo "$t|$cnt" done > source_counts.txt第二层是抽样内容校验。对每一张表按主键随机抽取若干行，比对关键业务字段。注意CLOB、TEXT这类大字段要用合适的抽样手段，避免直接全字段比对造成数据库压力。
第三层是自增列起点和序列状态校验。前面反复提到自增列起始值问题，这里要单独确认每张有IDENTITY列的表，当前自增起点必须大于源库现有最大主键，否则新增记录必然冲突。
5.2 统计信息收集与执行计划回归
数据迁移完成后，达梦的统计信息是缺失或陈旧的，优化器极可能按“0行数据”来估算执行计划。所以必须先做统计信息收集。达梦兼容Oracle风格的DBMS_STATS包，可以按Schema批量收集，我习惯在测试环境先验证系统包是否已初始化，再执行收集任务。
随后要回归历史慢SQL。迁移前把源库的慢查询日志和业务核心SQL捞一批出来，比如排序查询、分页查询、多表JOIN，迁移后在达梦上原样跑一遍，对比执行计划。重点看两类情况：
- 是否出现了全表扫描。尤其在排序规则变化、字段改为VARCHAR/CLOB之后，索引连接失效很容易触发。
- 是否出现了隐式转换。MySQL里能走索引的写法，在达梦上可能因为字符集或类型精度差异而不走索引，导致性能断崖。
5.3 应用连接与SQL兼容性切换
应用侧从MySQL切到达梦，核心动作是换驱动和改连接串。JDBC方式下，把mysql-connector-java换成达梦的DmJdbcDriver18.jar，驱动类改为dm.jdbc.driver.DmDriver，连接串改成类似：
jdbc:dm://192.168.1.10:5236?schema=APP如果是MyBatis或Hibernate这类ORM框架，确认好方言配置或对应适配版本，避免框架自动生成的分页SQL、序列SQL在达梦上报错。
我建议先做小流量灰度：让一个应用节点先连达梦，观察日志里的SQL异常，确认稳定后再全量切流。不要在同一时刻重启所有节点，否则一旦有SQL方言问题，影响范围会被拉满。
5.4 回滚预案：给自己留一条退路
即使验证全过，回滚预案也必须有。我的做法是：
- 迁移完成后，MySQL原库保持只读状态，至少保留一个观察窗口。
- 维护窗口内严格停写。如果业务无法接受停机，需要提前规划增量同步方案，比如通过应用双写或解析增量日志构建同步链路，不要指望迁移工具自动解决增量问题。
- 提前演练一次回退流程。包括如何从达梦导回MySQL、如何恢复应用配置、如何重新拉起原库服务。演练过才知道流程里哪里有坑。
上线后，如果决定从达梦再回退到MySQL，反向导出的工具和步骤也要提前验证，不能到回退前才临时上网翻文档。
最后分享一个我个人的习惯：每个迁移任务我都维护一张迁移对照卡，列字段包括表名、源库行数、目标库行数、主键策略、自增起点、关键索引、备注说明。每次排查“数据对不对、为什么查询变慢”这类问题，这张卡能省掉大量时间。另外，验证阶段一定要把线上慢日志里的SQL挑一二十条原样在达梦上跑一遍，这个动作比用任何校验工具都更接近真实业务场景。做完这些，再宣布“迁移完成”也不迟。
