去年下半年接了一个迁移的活儿把一套跑在 MySQL 上的业务系统整体搬到达梦数据库 DM8。原以为就是把表导过去、改改数据源连接串真正动手才发现卡住进度的全是 SQL 语法问题。MySQL 的方言习惯和达梦差得比想象中大从建表语句到分页、空串、自增列、存储过程每一层都有坑。这篇文章就把我这次 mysql 迁移达梦数据库期间遇到的具体问题、逐条改写方案以及最终确定的迁移方案完整记录下来给后续要做同样事情的人一个可参考的路线图。对于正在评估迁移方案的团队我的建议是先别急着买服务器装环境先拿现有系统的 DDL 和 TOP 20 SQL 跑一遍达梦兼容性检查。这个步骤能让你预估出真实的工作量也能帮你决定是用人工改写还是靠工具半自动转换。下面按我实际执行的顺序来写。1. 迁移前必须定下来的三件事1.1 实例初始化参数直接决定你要改多少 SQL达梦和 MySQL 最大的不同在于很多关键属性在初始化实例时就定死了后期无法通过配置文件调整。用达梦自带的 dminit 工具初始化实例时有三个参数必须认真确认页大小 PAGE_SIZE可选 4K、8K、16K、32K。我这次选的是 16K。原因很简单业务表里有不少大字段MySQL 端是 TEXT 类型迁移到达梦后建议转成 CLOB页大小太小会导致单行数据放不下后面建表频繁报错。字符集推荐直接选 UTF-8。如果选了 GB18030迁移后中文本身没问题但和 MySQL 端 utf8mb4 的字符串比较、排序行为会有细微差异应用层不易察觉排查起来却很头疼。大小写敏感 CASE_SENSITIVE这个最要命。生产环境如果选成了“大小写敏感”那么不加双引号的表名、列名会被自动转成大写MySQL 里习惯的小写表名到了达梦这边全部变成“无效的表名”。我在测试环境就吃过这个亏。测试库初始化时手滑选了大小写敏感结果 MySQL 端直接 mysqldump 出来的建表语句几乎全军覆没后面花了一整天才把这些 SQL 救回来。所以正式环境强烈建议初始化成“大小写不敏感”能帮你省掉大量改写工作。这个决定要在安装阶段就做等数据进去了再想改只能重新初始化实例。1.2 兼容模式尽量调到 MySQL达梦提供兼容模式参数可以模拟 MySQL、Oracle、SQL Server 等不同数据库的行为习惯。从 MySQL 迁移过来的项目建议优先把实例切换为 MySQL 兼容模式。切了之后LIMIT 分页、IFNULL 这类 MySQL 常见写法能直接用省去不少麻烦。不过我要提醒一句兼容模式不是万能药。它能帮你解决“函数名”“分页语法”层面的问题但存储过程、触发器这些复杂对象依然是达梦自己的 PL/SQL 方言迁移时还是得靠人工改写。所以我当时的策略是兼容模式改到 MySQL同时在项目规范里明确新 SQL 不要依赖 MySQL 特有语法能通用的写法尽量通用。另外兼容模式参数属于全局配置切换后大概率要重启数据库服务才能完全生效。千万不要在业务高峰期动这个参数也别指望改了立刻就能让所有 SQL 跑通。1.3 迁移对象清单要列全别只盯着表很多人在迁移时只关心“表和数据”等切库之后才发现视图打不开、存储过程全废、定时任务没搬过来。MySQL 侧一个数据库里通常包含以下对象迁移前要逐一登记表结构、约束、索引、自增列当前值表数据可能上亿行视图尤其是带算法的复杂视图存储过程、函数触发器事件调度器 EVENT对应到达梦要改造成作业 JOB自定义函数我给的建议是整理一张迁移对象核对表每迁移完一类就打勾。工具能自动处理的只有表和常规数据存储过程、触发器、作业基本靠手写早列清单早排人力。2. MySQL 与达梦的 SQL 语法差异全景2.1 数据类型映射不能想当然数据类型的差异在建表阶段就会暴露。下面是我这次实测下来最常用的一张映射表MySQL达梦 DM8注意事项INT / INTEGERINT正常迁移TINYINTSMALLINTMySQL 的 TINYINT(4) 表示显示宽度达梦没有这个语义直接去掉括号BIGINTBIGINT注意无符号 BIGINT UNSIGNED达梦不支持无符号需要用 NUMBER 类型绕VARCHAR(n)VARCHAR(n)达梦按字符长度计算基本一致TEXTCLOB大文本字段建议用 CLOB注意页大小BLOBBLOB二进制大对象迁移时容易超时建议分批DATETIMETIMESTAMP最直接的对应关系TIMESTAMPTIMESTAMP注意达梦主键列如果用 timestamp精度和默认值行为与 MySQL 不完全一致DATEDATE兼容DECIMALDECIMAL / NUMBER建议统一用 DECIMAL(p,s)ENUMVARCHAR CHECK 约束达梦没有枚举类型JSONCLOB 或达梦 JSON 类型如果应用用 MySQL JSON 函数建议先确认有没有替代函数BIT建议转 SMALLINTMySQL 的 BIT(1) 在达梦中没有直接对应这里最重要的经验建表语句不要直接拿来执行先做一遍类型转换的脚本替换再逐条看报错。失败的 DDL 达梦会用错误码和行号告诉你但一次性几十张表报错时还是提前转换更高效。2.2 建表语句反引号、ENGINE、CHARSET 全部要处理MySQL 的建表习惯和达梦差异很大。举个最典型的例子MySQL 端一张用户表CREATE TABLE user_info ( id int(11) NOT NULL AUTO_INCREMENT, name varchar(50) NOT NULL DEFAULT COMMENT 姓名, status tinyint(4) DEFAULT 1, remark text, gmt_create datetime NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_name (name) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4 COMMENT用户表;到达梦后改写为CREATE TABLE user_info ( id INT IDENTITY(1,1) NOT NULL, name VARCHAR(50) NOT NULL DEFAULT , status SMALLINT DEFAULT 1, remark CLOB, gmt_create TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id) ); CREATE INDEX idx_name ON user_info(name); COMMENT ON COLUMN user_info.name IS 姓名; COMMENT ON TABLE user_info IS 用户表;改写点逐个说反引号全部去掉。达梦默认不支持 MySQL 的反引号强行执行就是语法错误。如果某些标识符确实是关键字要用双引号包裹。ENGINEInnoDB、DEFAULT CHARSETutf8mb4、AUTO_INCREMENT100 这类 MySQL 专属表属性到达梦全是非法语法直接删除。AUTO_INCREMENT 改写成 IDENTITY(1,1)。如果兼容模式开启部分场景可能还支持 AUTO_INCREMENT 关键字但为了稳妥我建议在 DDL 里统一用 IDENTITY。KEY idx_name这种 MySQL 的索引简写达梦不认。要把索引单独提出来执行CREATE INDEX。列注释和表注释单独用COMMENT ON COLUMN / COMMENT ON TABLE执行。如果表数量多建议写一个正则批量替换脚本把KEY、ENGINE、CHARSET、反引号这些固定模式先清一遍再人工处理剩余报错。我这次大概有 200 多张表预处理脚本帮我省了至少半天时间。2.3 常用函数替换清单SQL 函数差异是运行时报错的主要来源。很多问题不是在迁移时报而是切库后业务跑着跑着报“无效函数名”。我整理了高频函数对照MySQL达梦 DM8说明IFNULL(a, b)NVL(a, b) 或 CASE WHEN兼容模式下 IFNULL 可能可用但 NVL 最通用IF(expr, a, b)CASE WHEN expr THEN a ELSE b END达梦没有 IF 函数DECODE 也可以NOW() / SYSDATE()SYSDATE / CURRENT_TIMESTAMP返回当前时间CURDATE()CURRENT_DATE返回当前日期DATE_FORMAT(d, fmt)TO_CHAR(d, fmt)格式串写法不同Y 和 M 的语义要仔细对STR_TO_DATE(s, fmt)TO_DATE(s, fmt)同理格式串不同GROUP_CONCAT(x)LISTAGG(x, ,)达梦的 LISTAGG 需要配合 GROUP BYSUBSTRING_INDEX需要自写或配合 INSTR/SUBSTRDM8 支持 INSTR可以组合实现FIND_IN_SET没有直接对应建议改写为 IN 或 LIKEDATE_ADD(d, INTERVAL 1 DAY)DATEADD(DAY, 1, d) 或 d 1达梦支持日期直接加减DATEDIFF(d1, d2)DATEDIFF(d1, d2)注意参数顺序两个库可能相反要实测这里给我印象最深的是 DATE_FORMAT。MySQL 的格式串%Y-%m-%d到达梦必须改成YYYY-MM-DD。看起来是小事但视图和存储过程里一旦出现就是批量报错。2.4 DML 和查询语句分页、INSERT、UPDATE JOIN 都是重灾区先说分页。MySQL 的经典写法是SELECT * FROM t ORDER BY id LIMIT 10, 20;达梦如果开启 MySQL 兼容模式多数情况下可以直接执行。但如果没开兼容模式或者版本对 LIMIT 支持不完善就要改成SELECT * FROM ( SELECT t.*, ROW_NUMBER() OVER (ORDER BY id) rn FROM t ) WHERE rn BETWEEN 11 AND 30;这里有一个技巧不要用 ROWNUM 来做分页。达梦和 Oracle 一样ROWNUM 是在排序之前分配的直接套 ROWNUM 取分页经常导致排序错乱。用ROW_NUMBER() OVER (ORDER BY ...)生成稳定的行号再按行号过滤结果才可靠。再说 REPLACE INTO 和 INSERT ... ON DUPLICATE KEY UPDATE。这两类 MySQL 写法在达梦中没有直接对应统一改成 MERGEMERGE INTO t2 t USING (SELECT 1 AS id, b AS name FROM DUAL) s ON (t.id s.id) WHEN MATCHED THEN UPDATE SET t.name s.name WHEN NOT MATCHED THEN INSERT (id, name) VALUES (s.id, s.name);GROUP BY 也要特别注意。MySQL 只要没开 ONLY_FULL_GROUP_BY允许查询非聚合列这会导致业务 SQL 里大量出现类似SELECT user_id, name FROM t GROUP BY user_id;达梦对 GROUP BY 的校验更严格这种 SQL 直接报错。改写思路是给非聚合列加聚合函数比如MAX(name)或者先确认业务到底需要哪条记录再改成子查询。UPDATE JOIN 和 DELETE JOIN 是另一类大坑。MySQL 可以写UPDATE t1 JOIN t2 ON t1.id t2.t1_id SET t1.name t2.name;达梦要改成UPDATE t1 SET t1.name ( SELECT t2.name FROM t2 WHERE t1.id t2.t1_id );DELETE JOIN 同理一般用子查询加 IN 的方式改写尽量不要两张表直接 JOIN 删除。2.5 存储过程和触发器基本靠人工重写这是整个迁移过程中最耗时、也最容易返工的部分。MySQL 的存储过程风格接近通用 SQL达梦则是 PL/SQL 方言变量声明、赋值、参数传递、游标写法都不一样。举个例子MySQL 存储过程CREATE PROCEDURE p_test(IN a INT) BEGIN DECLARE b INT DEFAULT 0; SET b a 1; INSERT INTO t(id) VALUES(b); END;到达梦要改成CREATE OR REPLACE PROCEDURE p_test(a IN INT) AS b INT : 0; BEGIN b : a 1; INSERT INTO t(id) VALUES (b); END;差异点很明显达梦不用 DECLARE 在 BEGIN 里声明变量而是在 IS/AS 后面用:直接初始化参数模式的位置从IN a INT变成a IN INT赋值从 SET 变成:。如果存储过程里再带游标、异常处理改写量更大。触发器也有类似的坑。MySQL 里NEW.col和OLD.col在达梦中要写成:NEW.col和:OLD.col冒号不能省。如果触发器里还有IF ... THEN ... END IF之类的逻辑基本可以直接参考 Oracle PL/SQL 的风格来改。我的建议是存储过程不要试图写自动化工具转换老老实实人工过一遍编译一个修一个。达梦管理工具里可以看到对象的编译错误信息按错误提示逐条修正反而比盲目套模板更快。3. 迁移方案的选型与完整实施路径3.1 三条路线怎么选DTS、Navicat、DataX达梦官方的数据迁移工具 DTS、Navicat Premium 的数据传输、阿里开源 DataX这三条路我都试过。直接说结论没有哪个工具能一招通吃组合使用效率最高。方案适合场景能迁移的内容缺点达梦 DTS 数据迁移工具首次全量、中小数据量、图形化操作表结构、数据、部分对象MySQL 驱动需要单独放大表容易中断Navicat Premium 数据传输小库快迁、开发环境临时拉数表结构、数据大表内存占用高报错中断后难续传DataX / 自研 ETL超大表、并行迁移、增量同步数据为主结构另建配置繁琐需要写 json人工 SQL 改写视图、存储过程、触发器、作业全部对象纯手工最耗时我这次用的是“DTS 迁数据 人工改对象”的组合。DTS 适合一次性把几百张表的结构和数据拉过来失败的表再单独补。DataX 更适合那种单表几个亿记录、需要断点续传的场景官方网站 json 模板都有MySQL Reader 到 Dm Writer 的插件也常见。这里有个容易被忽视的点DTS 连接 MySQL 时它需要读取 MySQL 侧的信息默认带的 MySQL 驱动可能版本太老连低版本 MySQL 也会报“无法加载驱动”。解决办法是手动把匹配版本的 mysql-connector-java.jar 放到 DTS 工具目录下的 lib 里重启工具再试。3.2 DTS 迁移的具体操作顺序DTS 图形化操作本身不复杂但顺序错了会浪费很多时间。我建议按下面的顺序来新建迁移工程新建迁移任务。源端选择 MySQL填地址、端口、库名、用户名、密码。目标端选择达梦 DM8填端口 5236对应账号密码。对象选择时第一次先不要全选只勾选 5 到 10 张小表跑通一遍。确认小表没问题后再勾选全部表开始全量迁移。迁移完成后查看迁移报告逐条处理失败记录。为什么一定要先跑小表因为迁移最容易在处理大字段、特殊字符、时间格式时出错。如果源表里有超过 4GB 的大字段或者数据里包含特殊不可见字符DTS 的默认参数可能处理不了先跑小表能提前暴露这类问题而不是等到全量跑到一半才发现。3.3 大表数据迁移DataX 和分批策略对于单表上亿行的情况DTS 全量跑一次动不动要十几个小时中途断了又得重来非常被动。这种表我建议用 DataX 做分片并行DataX 的 MySQL Reader 通过 where 条件或 splitPk 做分片Dm Writer 负责写入达梦。配置核心是把 querySql 按主键范围拆分成多个任务比如按 id 的区间拆成 500 万一段多个任务并行执行。一个简单的同步 json 结构{ job: { content: [ { reader: { name: mysqlreader, parameter: { connection: [{ jdbcUrl: [jdbc:mysql://ip:3306/db], table: [big_table] }], column: [id, name, gmt_create], splitPk: id } }, writer: { name: dmwriter, parameter: { connection: [{ jdbcUrl: jdbc:dm://ip:5236, table: [big_table] }], username: user, password: pass, column: [id, name, gmt_create] } } } ] } }DataX 的好处是任务失败后可以只重跑失败的分片任务不用全表重来。但表结构、索引、约束还是得先在目标库手动建好DataX 只负责灌数据。3.4 我实际执行的整体流程结合这个项目我最终跑通的流程可以拆成八步用 mysqldump 导出所有 MySQL 表结构不带数据、跳过注释。写正则脚本对 DDL 做批量替换去反引号、去 ENGINE/CHARSET、AUTO_INCREMENT 转 IDENTITY、TEXT 转 CLOB。在达梦测试库执行预处理后的 DDL收集所有报错并按错误类型分组。手工修正失败的 DDL修正完后再执行一遍直到全部建表成功。对几个小表用 DTS 做迁移验证核对字符集和自增起始值。全量大表采用 DTS DataX 并行方式迁移。手工改写并编译视图、存储过程、触发器、作业。在测试环境做业务回归抓 SQL 错误日志逐一修复后进入正式切换窗口。这个流程的核心是先做静态改写再动数据。数据迁过去很容易难的是表和对象能不能在目标库正常跑起来。先保证 DDL 全绿再灌数据后面问题会少一半。4. 迁移过程中的高发问题与排查方法4.1 模式错乱连接成功后却找不到表这是迁移后第一天最容易遇到的报错应用启动时报“表或视图不存在”或者“模式错误”。原因很简单达梦里“用户”就是“模式”。如果你用 SYSDBA 建的表表就落在 SYSDBA 模式下应用账号登录后默认访问同名模式自然找不到。解决方式通常有两种迁移前先为应用创建同名用户比如应用账号是 app就用 app 用户登录达梦建表这样表自动落在 app 模式下。在 JDBC 连接串中指定 schema例如jdbc:dm://127.0.0.1:5236?schemaAPP让应用默认访问 APP 模式。如果你用 Spring Boot 配置地址类似spring: datasource: driver-class-name: dm.jdbc.driver.DmDriver url: jdbc:dm://127.0.0.1:5236?schemaAPP username: APP password: xxxxxx这里还要注意大小写达梦的 URL 参数 schema 值如果和实际模式名大小写不一致会继续踩大小写敏感的坑。4.2 Druid 连接池拦截达梦方言后端用的是 MyBatis Druid Spring Boot迁移后遇到一个比较隐蔽的问题Druid 的 wall 防火墙会拦截掉它认为不合规的 SQL。达梦的一些方言写法在 Druid 的 SQL 解析器看来是异常语句直接抛出“sql not allowed”之类错误但 SQL 本身没问题。排查方法很直接先在配置里把 wall 过滤器关掉测试spring: datasource: druid: filter: wall: enabled: false如果确认是 wall 拦截导致生产环境建议用白名单方式放行业务 SQL而不是长期全关。另一个方案是升级 Druid 到较新版本新版本对多种数据库方言的识别更好。这个坑回头看其实算是连接池层面的适配问题和达梦本身语法无关但迁移时非常影响排查节奏。4.3 空字符串变成 NULL 导致业务数据异常MySQL 和达梦对空字符串的处理逻辑不一致这是个非常阴间的坑。MySQL 中是一个真实存在的字符串值和 NULL 完全不同。但达梦在默认行为下插入空字符串到 VARCHAR 列时可能被当作 NULL 存储。结果就是业务里原来WHERE name 的统计查询迁移后查不到任何数据因为表里根本没有空串只有 NULL。迁移完成后一定要做一轮数据质检重点检查源端为空的字符字段在目标端是否变成 NULLSELECT COUNT(*) FROM t WHERE name IS NULL OR name ;和源库执行同样 SQL 出来的行数做对比。如果差异集中说明这个字段存在空串语义应用层查语句要么统一改为同时兼容 NULL 和空串要么在迁移过程中用一个非空占位符替换空串。取舍很简单改 SQL 还是改数据哪个成本低选哪个。4.4 排序行为不一致导致页面翻页错乱排序这个问题容易被忽略。MySQL 和达梦对 NULL 的排序位置处理不同MySQL 升序时 NULL 在前达梦升序时 NULL 一般在最后。这意味着原来依赖默认排序的列表页面迁移后可能出现一排空数据或者数据错位。我的建议是不要把排序寄托在默认行为上。把表里可能为空的排序字段统一显式指定排序规则SELECT * FROM t ORDER BY gmt_create NULLS LAST;类似的还有字符串排序的 collation 规则。如果业务对排序要求严格迁移后要逐条比对两个库的排序结果而不是只看行数。4.5 常用排查速查表最后整理一份我在实战中反复用的排查清单遇到相似问题可以按这张表定位现象排查方向处理建议建表报“无效的表名/列名”标识符是达梦保留字或大小写敏感导致被转大写加双引号、改名或确认初始化参数为不敏感连接失败端口、驱动 jar、schema 配置确认 5236 端口放通替换匹配的 JDBC 驱动中文乱码服务器、客户端字符集不一致初始化时选 UTF-8应用连接串加 useUnicodetrue分页 SQL 报错兼容模式未生效LIMIT 语法不被识别改用 ROW_NUMBER BETWEEN或 FETCH/OFFSET 语法存储过程编译失败变量声明、赋值、参数位置不符合 PL/SQL参考 Oracle 风格逐步改写看编译错误详情触发器无效NEW/OLD 少了冒号统一替换为 :NEW / :OLD数据迁移后行数对不上空串转 NULL、大字段截断、自增列缺失按主键维度逐表对比 COUNT 和 SUM 指标迁移结束之后我最大的体会是工具能解决的只是搬运问题真正决定项目成败的是 SQL 方言的适配细致程度。如果你也在做类似的切换建议留出至少三分之一的时间专门处理语法兼容性。别被“一键迁移”的宣传带偏数据库的 WATER LEVEL 只有踩过一遍才知道深浅。先把上面这些差异在测试环境逐条过一遍后面正式切换就顺得多。