企业官网建设流程全解析

前阵子刚好负责把一个跑了多年的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与IDENTITY

MySQL建表时最常见的写法：

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风格的ROWNUM：

SELECT * 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风格）的差异非常大，我列几个高频替换：

改造中最容易出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连接串里常见的useUnicode=true&characterEncoding=utf8以及serverTimezone=Asia/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 典型报错与解决方案速查表

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之后、数据迁移之前，先让测试环境的应用单独连一台达梦库，把自动化回归测试跑一遍。这个动作能在一个下午内把大部分语法兼容问题一次性暴露出来，比上线后再排查高效得多。测试通过之后再开始正式的、大工作量的数据迁移，整个项目的风险会下降一大截。