前阵子刚好负责把一个跑了多年的MySQL业务系统迁到达梦数据库。说实话一开始大家都觉得“不就是换库嘛数据导过去就行”结果第一轮试迁就把我们干懵了——表结构倒是导进去了应用一启动满屏的SQL报错光语法兼容问题就改了整整两周。复盘之后发现这类迁移的核心难点从来不在数据搬移而在应用层那一堆“MySQL习惯写法”如何低成本地翻译到达梦语法体系里。这篇就把我们这次迁移过程中遇到的SQL语法问题、踩坑经过和最终沉淀下来的迁移方案完整梳理一遍给后面要干同样活儿的同学做个参考。1. 迁移前的整体评估别急着改代码很多人拿到迁移任务第一反应就是“先找个工具把数据导过去”这是最危险的路径。数据能过去不代表应用能跑起来。SQL方言差异才是真正的大头。我们这次迁移前其实没有做系统性的评估直接吃了大亏所以这里先复盘一下应该怎么做前期准备。1.1 先搞清楚达梦的兼容模式达梦数据库在初始化实例的时候是可以选择兼容模式的常见的配置下默认行为和Oracle高度接近比如空字符串等于NULL、标识符默认转大写这类“Oracle特性”都是默认开启的。这就意味着你写惯了MySQL的反引号、LIMIT分页、IFNULL、NOW()这一整套语法拿到达梦上大概率是不能直接跑的。另外要确认的是应用连到达梦实例时用的模式参数。达梦支持在会话级别或者数据源级别设置部分兼容行为但这个能力有限不能指望靠一个参数就把语法全兼容了。我建议迁移前先建一个测试实例把模式参数固定下来后续所有改造都在这个统一配置下进行免得开发环境一套、测试环境又变了。1.2 迁移复杂度评估的三个维度我后来总结出一个评估框架判断一个系统从MySQL迁到达梦的工作量主要看三块SQL静态分析把应用工程里所有Mapper XML、注解SQL、存储过程源码全部扫一遍统计用了多少MySQL特有语法。重点搜索的关键字包括LIMIT、IFNULL、NOW()、DATE_FORMAT、GROUP_CONCAT、反引号、ON DUPLICATE KEY UPDATE等。扫完基本能估算改造量级。对象类型摸底表、视图、索引、触发器、存储过程、定时任务每一类都要盘点。达梦对视图和存储过程的语法兼容性需要逐条验证尤其是存储过程里的异常处理和游标写法差异很大。数据特征分析最大表的行数、字段类型分布、是否有全文索引、是否有emoji字符、是否有特殊二进制内容。这些决定了数据迁移工具的参数选择和校验策略。1.3 制定分批迁移计划我们当时因为工期紧差点就搞“一步到位”被劝阻后才改成分批。正确的做法是先挑一个业务逻辑相对独立、数据量适中、读多写少的模块做“试点迁移”。试点模块跑通了验证整体流程没问题再扩大到全量。特别是有定时任务、消息队列消费这种后台链路的地方一定要单独列进迁移范围我当时差点漏掉两个定时任务还是迁移后查日志才发现。2. 最容易踩的SQL语法差异点详解这一部分是全文的核心也是我们被现实毒打最多的地方。每一条差异我都尽量给出MySQL原写法和达梦侧改造后写法方便直接对照。2.1 自增列AUTO_INCREMENT与IDENTITYMySQL建表时最常见的写法CREATE TABLE t_user ( id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(64) );这张表结构通过迁移工具导入达梦后如果工具能正确识别自增语义通常会转换为IDENTITY列CREATE TABLE t_user ( id INT IDENTITY(1,1) PRIMARY KEY, name VARCHAR(64) );但麻烦在于迁移只处理表结构应用侧如果还写了手动插入id的逻辑就会出问题。比如MySQL里你可以在紧急情况下INSERT INTO t_user(id,name) VALUES (100,test)指定主键但达梦的IDENTITY列默认是不允许显式插入值的。解决办法是临时执行SET IDENTITY_INSERT t_user ON;不同版本写法略有差异插完再关闭。如果旧表已经有大量数据且自增序号比较乱建议迁移时保留原id值同时把IDENTITY的种子值设为原表最大值1这个操作需要在迁移工具里手动调整否则后续应用插入记录可能报主键冲突。2.2 分页查询LIMIT与ROWNUM的分歧MySQL里随手就是SELECT * FROM t_order ORDER BY create_time DESC LIMIT 20, 10;达梦如果是Oracle兼容模式下LIMIT基本是直接报错的“关键字LIMIT附近出现语法错误”之类。有两种改造思路。第一种是治标写法用Oracle风格的ROWNUMSELECT * FROM ( SELECT t.*, ROWNUM rn FROM ( SELECT * FROM t_order ORDER BY create_time DESC ) t WHERE ROWNUM 30 ) WHERE rn 20;这里有个巨大的坑很多人第一反应是直接WHERE ROWNUM BETWEEN 21 AND 30这查不出任何数据。因为ROWNUM是结果集生成过程中逐行分配的条件里用ROWNUM 20永远不会成立。必须嵌套子查询先取前30行再在外面过滤。第二种思路是如果达梦版本较新、且初始化时开启了相应兼容参数LIMIT可能可以直接用。但这个稳定性我推荐不赌统一改造为ROWNUM写法最稳妥。如果系统里有几十上百处分页SQL建议封装一个分页查询基类或者统一模板别到处散着写。2.3 字符串与空值函数IFNULL、CONCAT这些老朋友这是改造量最大的一类问题。MySQL的IFNULL(a,b)到达梦Oracle风格下不识别要换成NVL(a,b)或者COALESCE(a,b)。我建议统一用COALESCE因为它是SQL标准两边都能用以后要再迁别的库也省事。CONCAT函数也要小心。MySQL的CONCAT支持任意多个参数比如CONCAT(a,b,c)。达梦在Oracle模式下CONCAT只接受两个参数多个参数会报错。两种改法要么嵌套写CONCAT(CONCAT(a,b),c)要么直接用||运算符Oracle风格推荐比如-- MySQL SELECT CONCAT(user_name, -, user_id) FROM t_user; -- 达梦 SELECT user_name || - || user_id FROM t_user;还有一个隐蔽问题MySQL中NULL参与字符串拼接的结果就是NULL达梦Oracle模式下同样如此但如果你之前依赖MySQL的CONCAT对NULL的容忍度实际上MySQL CONCAT遇到NULL也返回NULL倒还好说。真正要警惕的是GROUP_CONCAT这个函数在达梦里没有对应同名函数。Oracle风格下可以用LISTAGG但两者的排序、去重、分隔符行为有差异涉及这句语法的SQL基本需要重写。2.4 日期时间函数从NOW到SYSDATE的变迁日期函数是重灾区MySQL和达梦Oracle风格的差异非常大我列几个高频替换MySQL达梦Oracle风格备注NOW() / SYSDATE()SYSDATE / CURRENT_TIMESTAMP返回值基本一致CURDATE()CURRENT_DATE / TRUNC(SYSDATE)只取日期部分DATE_FORMAT(now(),%Y-%m-%d)TO_CHAR(SYSDATE,YYYY-MM-DD)格式符体系完全不同DATE_ADD(now(), INTERVAL 1 DAY)SYSDATE 1 或 DATEADD(DAY,1,SYSDATE)Oracle里整数加天数DATEDIFF(a,b)直接做减法如(a-b)结果需确认单位是天UNIX_TIMESTAMP()没有直接等价需用函数组合建议应用层处理改造中最容易出bug的不是单个函数替换而是嵌套场景。例如MySQL里WHERE create_time DATE_SUB(NOW(), INTERVAL 7 DAY)单独替换成SYSDATE - 7没问题但如果你多次套用、还牵扯时区问题就会混乱。我的建议是所有日期时间相关SQL集中到DAO层改造之前先统一应用侧的日期传入方式最好由代码传入时间参数而不是在SQL里写死函数这样不仅迁移顺利以后排查问题也更容易。2.5 布尔类型、反引号与保留字问题MySQL里很常见的TINYINT(1)做布尔位迁移到达梦一般会映射为NUMBER(1)这个本身还好。但代码里如果写WHERE is_deleted 1没问题如果写WHERE is_deleted IS TRUE那就要报错了达梦里没有TRUE/FALSE字面量在Oracle风格模式下。要么改成1要么建表时用BIT类型达梦也支持看团队习惯。反引号是MySQL独有的达梦完全不认。例如SELECT id, name FROM t_user;在达梦里直接报错。大部分情况下直接把反引号删掉即可。但要注意两类特殊情况一是表名或字段名命中了达梦的保留字比如comment、desc、level、rows这种在MySQL里用反引号包着没事的删掉反引号后达梦会报“此处不允许使用保留字”。这时候要么给字段加双引号注意双引号在Oracle风格下表示大小写敏感标识符麻烦事多要么直接改字段名。我强烈建议走改名路线一劳永逸SQL也干净。2.6 其他隐蔽差异GROUP BY、NULL排序、隐式转换这几个问题不常见但一出现就是“线上事故级”的定位难度。GROUP BY的宽松与严格。MySQL默认允许SELECT name, age FROM t_user GROUP BY age这种“非聚合列不在GROUP BY里”的写法捡到哪个是哪个。达梦Oracle风格下会直接报ORA-00979: not a GROUP BY expression。必须把SELECT里的所有非聚合列加进GROUP BY或者对列用聚合函数包一层。这一块靠静态扫描都不一定扫得全因为只有执行到才会触发。NULL排序。MySQL里ORDER BY create_time ASC时NULL排最前面达梦Oracle风格下NULL默认排最后。影响虽然不大但如果有“置顶最近更新”之类的业务逻辑排序结果会悄然变化。需要保持MySQL语义的话要写ORDER BY create_time ASC NULLS FIRST。隐式类型转换。MySQL对字符串和数字的比较非常宽容比如WHERE user_id 123abc它会把字符串转成数字123达梦则可能直接报“无效的数字”这类转换错误。这类问题只能靠回归测试慢慢暴露在改造阶段就要强调代码评审时关注传入参数类型是否严谨。3. 迁移方案设计与实操流程踩完语法坑完整的迁移方案才能真正跑起来。我按阶段梳理一个经过验证的实操流程尽量把每一步的关键动作和检查点写清楚。3.1 表结构与数据库对象转换第一步先处理结构。我建议不要完全依赖迁移工具的自动转换工具导完之后一定要人工核对以下几类对象约束主键、唯一键、外键要逐个确认名字和字段是否一致注意外键的ON UPDATE CASCADE在达梦里不一定支持需要评估是否要删除级联更新逻辑改由应用层兜底。索引普通索引和唯一索引迁移基本没问题但MySQL的FULLTEXT全文索引在达梦里没有等价物需要重建为达梦的全文索引语法较为繁琐。如果业务对全文检索依赖不深建议先把相关SQL改为LIKE查询或者引入独立检索引擎。视图视图能自动转但转换后一定要做一次SELECT * FROM 视图名 WHERE rownum 10的抽样验证很多视图在工具转换后存在字段别名丢失或者多层嵌套语法错误编译能过不代表能查出数据。存储过程/触发器这些是兼容性风险最高的对象。达梦支持类似Oracle的PL/SQL语法但MySQL的DELIMITER写法、DECLARE位置、异常处理SIGNAL SQLSTATE等在达梦里都不适用。如果原系统有大量存储过程建议专门抽一个阶段集中改造不要和普通SQL混在一起。结构核对阶段还有一个重要动作确认字符集。如果原MySQL库是utf8mb4且数据里有emoji达梦建库时必须选择对应支持四字节字符的字符集比如UTF-8。否则数据迁移时会报编码错误或者在库里存成乱码。这个在建实例那一关就要确认好。3.2 数据迁移方法与校验数据迁移我们用的是达梦自带迁移工具整体流程是配置源MySQL连接-配置目标达梦连接-选择需要迁移的对象表、视图、存储过程等-核对字段映射-执行迁移。几个实操经验关于批量提交大表迁移时建议按自定义查询条件分批抽取比如WHERE id BETWEEN ? AND ?分片跑不要用单条INSERT。迁移工具支持自定义SQL抽取能很大程度避免大事务带来的内存压力。关于超时MySQL端如果数据量很大连接超时时间要调大特别是读超时。我们有一张几千万行的流水表用默认配置跑了一个多小时就断了后来把连接参数调大、分片之后才跑完。行数校验不能只对总数总数一样不代表内容一样。我们当时除了对比行数还对每张表做了一次SELECT MIN(id), MAX(id), COUNT(DISTINCT 某个关键字段)的分组对比再抽几百行数据做全字段内容比对。有条件的话用程序把源端和目标端的某几个关键业务表的行哈希算一遍比对哈希值排查效率会高很多。3.3 应用侧SQL改造规范这是整个迁移中耗时最长、最需要“死磕”的环节。我们最终把它做成了一个标准动作每个研发都按这套规范自查禁用关键字列表把MySQL特有语法整理成表格贴在项目文档里包括LIMIT、IFNULL、NOW()、DATE_FORMAT、GROUP_CONCAT、ON DUPLICATE KEY UPDATE、REPLACE INTO、反引号等代码评审时直接按清单查。批量替换工具对IFNULL改成COALESCE、NVL改成COALESCE这种纯文本替换可以用脚本批量处理但替换完必须人肉细看。我提醒一句IFNULL嵌套的时候自动替换容易出错因为MySQL的IFNULL只有两个参数COALESCE虽然支持多个参数但嵌套括号位置处理不好语义会变。MyBatis XML专项检查如果是Java技术栈大量SQL都在XML里。可以把所有XML文件用脚本扫一遍找出包含上述关键字的SQL片段生成一个改造清单。这里建议把所有XML格式化后统一导入一个文本检索工具按关键字逐个过会高效很多。容易漏的是动态SQL里的script标签内的判断条件这部分MyBatis的逻辑和数据库语法无关但拼接出来的SQL可能直接踩雷。连接层配置应用数据库连接池的初始化连接参数要同步调整。MySQL连接串里常见的useUnicodetruecharacterEncodingutf8以及serverTimezoneAsia/Shanghai这类参数在达梦驱动上是不识别的要确认达梦驱动是否要求设置时区。另外连接池的validation query一般MySQL是select 1达梦同样支持SELECT 1 FROM DUAL但也可以直接用SELECT 1需要看驱动版本。最快的方式是新建一个测试应用把连接池配置好启动一次看日志。3.4 全链路验证与上线切换SQL改完、数据迁完只能算测试环境通过。上线前的验证我建议按这个顺序做接口回归把应用完整连到达梦测试库用自动化测试把所有核心接口跑一遍重点比较返回明细数据是否和MySQL环境一致。定时任务验证手动触发一遍所有定时任务确认调度正常、SQL执行无报错。MySQL的EVENT定时任务到达梦后通常要改写成达梦的作业系统这一步经常被忽略。性能基准对比选几个核心查询SQL分别看MySQL和达梦的执行计划确认索引是否命中、扫描行数是否合理。达梦的执行计划可以通过EXPLAIN SQL查看和Oracle的EXPLAIN PLAN相似。灰度切换真正上线时先切一部分只读业务流量到达梦环境确认日志无异常、业务反馈正常后再切写流量。如果条件允许晚一步切换的应用继续保持连接MySQL这样出问题还能及时回滚。4. 常见问题排查与避坑速查迁移过程中我们会不断遇到新的报错很多报错信息长得像Oracle但实际根源还是“MySQL习惯没改干净”。这里整理一张速查表基本覆盖我们遇到过的典型情况。4.1 典型报错与解决方案速查表报错信息或现象常见原因解决办法ORA-00942: table or view does not exist表名大小写不一致MySQL里小写到达梦被转成大写导致找不到统一表名大小写策略要么全小写建表并设置参数要么SQL中明确用双引号ORA-00904: invalid identifier字段名是保留字或大小写不一致修改字段名或查询时对该字段加双引号ORA-00979: not a GROUP BY expression非聚合列未包含进GROUP BY改造SQL将所有非聚合列加入GROUP BYORA-00933: SQL command not properly ended常见于LIMIT、ON DUPLICATE KEY UPDATE未转换改造为ROWNUM或MERGE INTO语法ORA-01756: quoted string not properly terminated保留了MySQL反引号全局删除反引号执行时报“无效的数字”字符串与数字比较的隐式转换查询参数改为数字类型或SQL中显式CAST插入数据报“字符串截断”目标字段长度小于源数据常见于VARCHAR映射错误重新核对字段长度映射增大目标字段长度空字符串被当作NULLOracle模式默认行为如业务区分空串和NULL需要应用层改造中文排序混乱字符集或排序规则不一致确认建库字符集必要时配置达梦排序规则4.2 迁移后性能反而不如MySQL的排查迁完之后遇到的另一个糟心事是“同样的SQL在MySQL秒出到了达梦要好几秒”。这类问题基本不是语法兼容而是达梦侧的统计信息和执行计划问题。排查步骤建议这样走确认统计信息是否最新。数据导入完成后达梦不会自动采集统计信息必须手动执行统计信息收集语句类似于DBMS_STATS.GATHER_TABLE_STATS否则优化器对行数的估算完全不准可能选择全表扫描。分析执行计划。拿一条慢SQL到达梦的客户端里执行EXPLAIN看是不是有“全表扫描”和“无需索引进表”。常见原因是索引没有随着数据迁移同步完成或者迁移工具丢了索引名。重新创建索引后性能通常立竿见影。查询条件用了函数包裹索引列。比如把create_time字段用TO_CHAR(create_time,YYYY-MM-DD)和传入字符串比较索引大概率失效。改造时应该让查询条件保持create_time TO_DATE(2024-01-01,YYYY-MM-DD)这类写法索引才能用上。分页相关性能。ROWNUM嵌套分页如果内层排序字段没有索引就会先全局排序再取页成本极高。建议给排序字段建组合索引或者考虑用达梦新版本对分页语法的原生支持。4.3 字符集与排序规则细节除了建库时选UTF-8还有一个细节容易被坑MySQL的utf8mb4_unicode_ci排序规则和达梦默认的中文排序规则不一致可能导致ORDER BY name的结果顺序与预期不同。如果对比新旧系统导出的列表发现顺序不一样排查点就在排序规则。这种差异通常不影响功能正确性但在做分批对比校验时会造成“人为diff”浪费时间。另外如果源MySQL里同时存在多种字符集比如某些字段是latin1、有些是utf8mb4迁移工具映射时很容易出现字段级乱码。我的习惯是迁移前先在MySQL侧统一把所有表的字符集修成utf8mb4再执行迁移可以省去很多麻烦。4.4 工具选型与驱动注意事项迁移工具选择上用达梦自带的迁移工具基本够用但有几个点要特别注意工具自动生成的建表语句可能不够优化比如把所有VARCHAR统一映射成VARCHAR2(4000)导致存储膨胀。导出后建议人工review一遍核心表的字段定义。迁移工具版本和达梦数据库版本要匹配版本不一致会导致某些大字段类型转换失败。JDBC驱动要换到达梦对应版本的驱动不要用MySQL驱动去连达梦这不是“连接串改改就行”的事。驱动选错最典型的现象是应用启动报Unable to load authentication plugin caching_sha2_password这其实是在拿MySQL驱动连达梦。连接串里的时区和字符集参数在达梦驱动上写法完全不同建议以达梦官方文档为准不必试图兼容MySQL参数。5. 几个压箱底的迁移心得这些经验不是我一开始就知道的完全是这次迁移被反复折磨之后才总结出来的写在这里等于把血泪教训直接交给你。第一先做一次“预迁移”再做正式迁移。无论你对系统评估得多到位都建议先挑一个模块做一次完整的预迁移包括建表、导数据、应用切换、回归测试。预迁移能暴露大量意料之外的问题而且这些问题越早知道后面的整体计划越可控。第二SQL改造不要“边查边改”要“批量扫描重点人工复核”。人肉逐条找SQL效率极低很容易遗漏。先把代码仓库里所有涉及数据库操作的文件统一导出来用脚本扫描关键字生成问题清单然后按清单逐条修改。修改完再让另一个同事做代码评审专门复核那些嵌套嵌套再嵌套的写法。第三严格区分“数据库兼容”和“应用适配”两类工作。数据库侧的视图、存储过程、作业这些是DBA能处理的应用侧的SQL写法、类型转换逻辑、连接参数必须研发团队投入DBA帮不了。早一点拉清楚责任边界推进节奏就会顺很多。第四上线后的一周内不要放松。很多兼容性问题是线上偶发参数触发的比如某个接口传入异常值才走进某条SQL分支。迁移后第一周我建议每天都看一遍应用日志里的SQL异常同时对比新旧系统的监控指标一旦发现某个接口报错立刻按上面那张速查表定位。最后再分享一个小技巧如果你手头有完整的自动化回归测试在改完SQL之后、数据迁移之前先让测试环境的应用单独连一台达梦库把自动化回归测试跑一遍。这个动作能在一个下午内把大部分语法兼容问题一次性暴露出来比上线后再排查高效得多。测试通过之后再开始正式的、大工作量的数据迁移整个项目的风险会下降一大截。