MySQL迁移达梦数据库SQL语法差异与兼容性避坑指南

干了这么多年数据迁移，MySQL换到达梦这种国产数据库的活儿，我接过不止一次。说实话，每次听到"MySQL迁达梦"这几个字，第一反应不是工作量，而是语法兼容性这个雷区。很多团队在迁移前做了一堆表结构设计和数据全量备份的规划，结果一上应用，SQL一跑，直接报错，然后整个项目卡在联调阶段进退两难。这篇文章我就从实际踩过的坑出发，围绕SQL语法差异和整套迁移方案，把那些不跑一遍根本发现不了的问题捋清楚。

先交代一下我的经历背景。我之前负责过一个业务系统的国产化改造，源端是MySQL 5.7，目标端是达梦8（DM8），数据库体量大概是400多张表、接近1TB的数据，应用层同时涉及Spring Boot + MyBatis和一套报表系统，整体迁移周期压缩在三周内。所以从部署、迁移、SQL改写、应用适配到验证切换，基本每个环节都被逼着快速过了一遍。这也是为什么我对达梦在迁移上的那些"坑位"记得特别清楚。

1. 迁移踩雷前的第一课：达梦不是换个连接串就能跑的

很多开发第一次接触达梦，下意识会把它当成"MySQL的平替"，觉得都是关系型数据库，改个驱动、改个URL、把分号一加就完事。这个想法本身就有问题。

1.1 达梦的兼容模式：你在用MySQL模式还是Oracle模式

达梦数据库最特殊的一点，是它支持多种兼容模式。初始化实例的时候，有一个初始化参数叫COMPATIBLE_MODE，这个参数直接决定了后面你会遇到多少SQL语法问题。

如果COMPATIBLE_MODE=0，这是达梦的默认模式，语法向Oracle靠拢；如果COMPATIBLE_MODE=4，则是MySQL兼容模式，很多MySQL特有的语法会被识别。

先说一个非常容易踩的坑：很多项目初始化实例时根本没人关注这个参数，直接默认值装完就开干。结果应用层用的是MySQL的LIMIT分页语法、反引号引字段名这类写法，达梦在Oracle模式下全都认不出来，于是报错一片。我第一次做达梦迁移项目时，就被这个参数坑过，一开始以为是驱动问题，查了半天才发现根子上兼容模式就选错了。

所以我的建议是，如果源端是MySQL且应用层几乎不改SQL，那么在初始化达梦实例时就要明确设置COMPATIBLE_MODE=4，后续的迁移会省掉大量改写工作。如果是老系统里的Oracle迁移，那就保持默认模式。最怕的是根本没想过模式这回事，装完直接导数据写应用，最后两头不靠。

这里补充一下，达梦安装包在Linux环境下的安装，尤其是麒麟V10这类国产操作系统上，还需要检查glibc版本和系统位数，部分场景需要配置环境变量DM_HOME和LD_LIBRARY_PATH。Windows环境下安装反而简单，直接双击安装包按向导走即可。但无论哪个平台，初始化实例时的兼容模式参数都要规划好，这是迁移的第一决策点。

1.2 工具链：DBeaver、Kettle、Navicat到底能不能用

达梦官方提供了数据库管理工具DM管理工具，这个工具本身能用，但说实话，界面和操作习惯跟Navicat差得有点远，很多开发者不太爱用。于是大家习惯性地想用Navicat、DBeaver去连达梦。

• DBeaver连接达梦：DBeaver本身没有内置达梦驱动，但可以通过"数据库驱动管理器"添加达梦JDBC驱动（DmJdbcDriver18.jar）实现连接。驱动包在达梦安装目录的drivers/jdbc下可以找到。连的时候URL格式是jdbc:dm://IP:5236。DBeaver的通用性确实好，很多SQL排查工作我都是直接用它做的。
• Navicat连接达梦：新版本的Navicat Premium是支持达梦数据库连接的，如果连不上，检查一下版本，旧版本确实不支持。
• Kettle（PDI）连接达梦：需要下载达梦的JDBC驱动，并在Kettle的lib目录下放置驱动包，然后在数据库连接里选"Generic database"，自定义连接URL和驱动类名。

这里有个经验，工具链能成功连上只代表JDBC/ODBC层面通，不代表SQL语法层面兼容。很多工具连上后照样不能执行MySQL特有的语法，因为语法解析是在达梦服务端做的，跟工具本身无关。所以排查语法问题，第一选择应该是达梦自带的"DM管理工具"或者命令行disql，因为它给出的报错信息更贴近达梦的解析逻辑。

2. 语法兼容性排查：一个别名引发的报错排查链路

标题里有一个非常典型的问题——"达梦数据库 别名 model 报错 m 不报错"。这个看起来特别像玄学，一个别名一会儿能用一会儿不能用，搞得很多开发一头雾水。

2.1 问题复现：MODEL作为别名需要加双引号

我们当时遇到的实际场景是这样的：

sql复制-- MySQL正常执行
SELECT id, name AS model FROM user_info;

-- 到达梦（Oracle兼容模式）则报错
SELECT id, name AS model FROM user_info;
-- 报错信息：第1行, 第25列, 此处出现无效的列名或表达式: MODEL

但同样的语句，如果别名换成一个普通字符比如m：

sql复制SELECT id, name AS m FROM user_info;

就完全没问题。

当时第一反应是"达梦的SQL解析器有病吧"。后来查了达梦官方文档和社区案例才发现，MODEL在达梦数据库里是保留关键字之一，用来支持MODEL子句（用于构建多维分析查询）。保留关键字不能直接作为标识符使用，除非使用双引号包裹。

正确的写法是：

sql复制SELECT id, name AS "model" FROM user_info;

或者干脆改别名，不要叫model。

但这里有一个更隐秘的坑：在达梦里，如果关键字用双引号包裹，且双引号内的字母不是全大写，那么达梦会把双引号内的内容当作一个大小写敏感的标识符来对待。也就是说"model"和"MODEL"是两个不同的标识符。这跟我们平时在MySQL里的习惯完全不同——MySQL在Linux下默认区分表名大小写，但列别名通常不区分，而且反引号包裹的内容不会改变大小写语义。

2.2 排查过程：从报错信息到官方文档再到构造最小复现

我详细说一下排查这类问题的方法，因为这类问题在迁移中绝不是个例，而是一类问题。

第一步，先用达梦自带工具执行出错的SQL，查看报错行号和列号。达梦的报错信息一般会明确到"第几行、第几列"，这比MySQL的报错更精确。

第二步，把SQL中涉及的别名、表名、字段名逐个检查，看是否命中了保留字/关键字。达梦的DM管理工具里可以执行：

sql复制SELECT * FROM V$RESERVED_WORDS WHERE WORD = 'MODEL';

或者直接去达梦安装目录下的doc文件夹里翻DM8_SQL语言使用手册.pdf，里面有完整的保留字列表。

第三步，做了一个最小化复现实验，逐步删除SQL中的子句，定位到是别名的问题而不是其他因素。这一步很重要，它能帮你确认问题是否真的是由某个关键字触发的，而不是被其他子句干扰。

第四步，在官方文档或社区确认该关键字是否有特殊用途。比如Model子句确实存在，那么作为别名就必须加双引号。

这类"关键字作为标识符"的问题，在迁移中出现的频率比想象中高得多。除了MODEL，我们还遇到过COMMENT、ORDER、GROUP、ROWNUM、UID、LEVEL等在不同场景下被达梦识别为保留字的情况。

2.3 迁移中的"脏数据"动态SQL：别名不能写进动态语句

这里还有一个值得单独说的场景。很多系统会在MyBatis的映射文件里写动态SQL，比如：

xml复制<select id="getData" resultType="map">
    SELECT
    <choose>
        <when test="alias != null">name AS ${alias}</when>
        <otherwise>name</otherwise>
    </choose>
    FROM user_info
</select>

如果传入alias的值为model，那么在MySQL中没问题，到了达梦就直接报错。这类问题的隐蔽性在于，它不是静态写在XML里的，而是运行时拼接出来的，所以在开发环境根本测不出来，一上生产就崩。

我的建议是，在迁移过程中对代码仓库做一次全量文本扫描，把所有select语句中出现的别名、表名字段名提取出来，跟达梦的保留字列表做一次查重。虽然不能100%覆盖动态拼接的边界，但至少能提前暴露90%以上的静态风险。

3. MySQL和达梦SQL语法差异：一张对照表看清核心区别

这一节我整理一下两个数据库之间最常见、最能引发迁移事故的语法差异。这里说明一下，以下内容是围绕达梦的MySQL兼容模式（COMPATIBLE_MODE=4）和默认Oracle兼容模式的综合对比，因为在真实的迁移项目中，很多团队并不会严格只用一种模式。

3.1 标识符引用方式

在MySQL中，标识符默认是用反引号包裹的，例如：

sql复制SELECT `id`, `name` FROM `user_info`;

而达梦数据库（无论什么模式）默认使用双引号表示标识符引用。如果在达梦的Oracle模式下用反引号，直接报语法错误；在MySQL兼容模式下，部分版本支持反引号，但为了保险起见，迁移时建议把反引号全部改成双引号或者去掉。

另外，MySQL中字符串字面量用单引号和双引号都可以，而达梦默认也是支持两种，但双引号如果被解析器识别为字符串，在某些复杂语句中会产生歧义。所以，代码里最好统一用单引号表示字符串，双引号表示标识符。

3.2 分页查询语法

MySQL的分页是这个：

sql复制SELECT * FROM user_info LIMIT 10, 20;

达梦Oracle模式的分页长这样：

sql复制SELECT * FROM (SELECT t.*, ROWNUM rn FROM user_info t WHERE ROWNUM <= 30) WHERE rn > 10;

或者使用达梦对Oracle的ROWNUM封装：

sql复制SELECT * FROM user_info LIMIT 20 OFFSET 10;

其实达梦在兼容模式下也支持LIMIT OFFSET，但这里要特别注意：如果只是把MySQL的LIMIT 10, 20原封不动搬到达梦，达梦的解析方式可能跟MySQL预期不一致。MySQL的LIMIT 10, 20代表"偏移10，取20条"，而达梦虽然支持类似的写法，但语义存在版本差异。

我的建议是，在代码层统一封装一个分页工具，由工具生成对应数据库方言的分页SQL，而不是在业务里写死LIMIT。

3.3 自增列的写法

MySQL的自增列是在建表语句中写AUTO_INCREMENT：

sql复制CREATE TABLE user_info (
    id INT NOT NULL AUTO_INCREMENT,
    name VARCHAR(50),
    PRIMARY KEY (id)
) ENGINE=InnoDB;

达梦在MySQL兼容模式下支持AUTO_INCREMENT，但在Oracle模式下则使用IDENTITY列，或者通过序列+触发器的方式。达梦8的Oracle模式默认支持IDENTITY：

sql复制CREATE TABLE user_info (
    id INT IDENTITY(1,1) NOT NULL,
    name VARCHAR(50),
    PRIMARY KEY (id)
);

如果表结构是通过工具自动转换的，就要特别检查自增列的转换情况。我们当时有一个表结构是从MySQL的AUTO_INCREMENT直接复制到达梦的，结果数据能插入但主键不自增，最后排查发现是达梦建表语句没有正确触发生成自增序列的逻辑。

3.4 字符串拼接

MySQL的字符串拼接我们习惯用CONCAT函数，也可以用双竖线||（但MySQL里默认||是逻辑或，需要设置PIPES_AS_CONCAT）。

达梦默认支持||作为字符串连接符，这一点跟Oracle一致。比如：

sql复制SELECT 'Hello' || ' ' || 'DAMENG' FROM dual;

同时也支持CONCAT函数，但**CONCAT函数在达梦和MySQL中对于参数数量和处理NULL的规则可能不同**。MySQL的CONCAT如果任何一个参数为NULL，返回NULL；达梦的CONCAT同样有这个行为，但两个参数的CONCAT在部分旧版本中不太一样。稳妥的做法是：迁移时把CONCAT调用改成||运算符。

3.5 GROUP BY的兼容性差异

MySQL有一个著名的特性，ONLY_FULL_GROUP_BY关闭时，SELECT子句中允许出现不在GROUP BY子句中的非聚合列：

sql复制SELECT id, name, COUNT(*) FROM user_info GROUP BY dept_id;

这在达梦中会直接报错，因为达梦对分组查询的校验比MySQL严格得多。迁移时遇到这类SQL，要重写为：

sql复制SELECT MAX(id) id, MAX(name) name, COUNT(*) FROM user_info GROUP BY dept_id;

3.6 外连接写法

MySQL中的外连接写法：

sql复制SELECT * FROM a LEFT JOIN b ON a.id = b.aid;

达梦中完全支持这种标准写法，但同时达梦也支持Oracle风格的(+)连接：

sql复制SELECT * FROM a, b WHERE a.id = b.aid(+);

在迁移时，建议直接使用标准的LEFT JOIN写法，避免(+)带来的连接方向混淆。同时要注意，如果原来的MySQL SQL中出现了IFNULL、NOW()、CURRENT_TIMESTAMP()这类函数，在达梦中需要替换为NVL、SYSDATE或CURRENT_TIMESTAMP（要确认具体版本是否支持）。

3.7 函数与伪列：NVL、SYSDATE、ROWNUM

这些是从Oracle模式继承下来的重点：

GROUP_CONCAT这个函数在迁移中也是一个高频雷区。我们有一个报表系统大量使用了GROUP_CONCAT把分组内的多个值拼成字符串，到达梦后默认不支持，后来统一替换成LISTAGG才把问题解决。

3.8 达梦的MODEL子句与别名MODEL的关系

再说回MODEL。达梦对MODEL关键字的支持，主要是为了兼容Oracle的MODEL子句，用于在SQL中实现类似电子表格的数组计算。这个特性平时很少有人用，但它的存在导致MODEL成了保留字。这也是为什么别名model在解析器中会被当作关键字而非标识符的原因。

这个问题在MySQL中完全不存在，因为MySQL没有MODEL子句，MODEL在MySQL中只是一个普通单词，可以做别名。两个数据库的保留字集合不同，所以"在MySQL里能跑、到达梦就报错"的这个现象就成了迁移中最常见的拦路虎。

4. 迁移方案的整体设计与实施路径

语法问题只是迁移中最大的一类"显性"问题，真正完整的迁移项目还包括结构迁移、数据迁移、应用适配、校验与切换。这套流程我们跑下来，是有一套相对标准的方法的。

我认为整个迁移流程可以拆成七个步骤：需求与现状梳理、环境准备、结构迁移、数据迁移、SQL与应用适配、数据校验、切换与回滚方案设计。下面重点讲几个容易出问题的环节。

4.1 表结构迁移：不要全信工具，手工检查索引和注释

表结构迁移最理想的方式是用达梦自带的DTS（数据迁移工具）或者DM数据迁移工具直接从MySQL源库抽取表结构。但在实际执行中，工具生成的建表语句并不完美，主要有几个问题：

• 字符集/排序规则丢失：MySQL的utf8mb4在达梦中可能需要映射为UTF8，但具体映射规则依赖版本，有时会变成乱码。
• 索引类型变化：MySQL的BTREE、HASH索引，到达梦后可能统一变成达梦默认索引，工具不一定会提示。
• 注释丢失：部分工具在迁移表结构时不会把COMMENT完整带过去，导致后期数据字典缺失。
• 自增列转换错误：上文提到过的AUTO_INCREMENT转换为达梦IDENTITY的问题。

我的建议是：DTS做完结构迁移后，再用一个脚本对比源端和目标的表结构元数据。通过查询信息模式：

MySQL端：

sql复制SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_COMMENT
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_db';

达梦端：

sql复制SELECT TABLE_NAME, COLUMN_NAME, DATA_TYPE, NULLABLE, COMMENTS
FROM USER_TAB_COLUMNS;

把两边导出的元数据做成Excel比对，重点看数据类型映射和默认值。这一步虽然繁琐，但能省去后续大量"字段对不上"的麻烦。

4.2 数据迁移：大数据量下的实践选择

数据迁移我们当时对比了三种方式：

最后我们采用的是"DTS全量 + 自定义增量校验脚本"的组合方式。DTS全量迁移时要注意，如果表特别大，建议分批抽取，不然DTS内部的内存分配会撑不住。另外，DTS迁移过程中如果报错中断，下一次重启迁移时一定要先确认目标表里是否已经存在部分数据，否则很容易重复插入。

还有一种常见情况是主键冲突。MySQL表里的AUTO_INCREMENT在迁移后，如果目标表的IDENTITY种子没有正确设置，可能导致部分数据插入失败。

4.3 应用层SQL适配：从MyBatis到JDBC的排查策略

应用层SQL适配是整个迁移中最费时间的部分，因为代码仓库里的SQL不会一次性暴露所有问题，往往是跑到哪个功能模块才爆出哪个SQL问题。我的做法是分三步：

第一步，全局扫描。扫描代码中的.xml文件（MyBatis）、.java文件（JDBC）、.sql脚本中的SQL语句，先做静态检查，找出以下高风险模式：

• LIMIT分页
• 反引号
• GROUP_CONCAT
• IFNULL
• NOW()
• 关键字作为表名/字段名/别名

第二步，构建兼容性测试矩阵。把扫描出来的SQL语句跑在一个专门搭建的迁移测试环境上，用真实的达梦库执行一遍，所有报错的SQL汇总成一张问题清单。

第三步，逐条改写并回归验证。改写时优先利用达梦的MySQL兼容模式来减少改动量，但不要完全依赖兼容模式，毕竟它不是100%等价。

这里还要提一个常见的坑：MyBatis的useGeneratedKeys和keyProperty在达梦上的表现。MySQL中使用useGeneratedKeys可以获取自增ID，达梦在兼容模式下也需要支持，但实测下来部分达梦版本在批量插入时不能正确返回自增ID。如果遇到这个问题，建议改成通过序列显式获取ID，或者用达梦的IDENTITY返回机制做适配。

4.4 SQL代码排版的配合价值

在SQL改写过程中，我会把所有的SQL先做一次标准化排版。这不是为了好看，而是为了在对比修改前后的差异时减少噪音。我们当时用了一个SQL排版工具，把换行、缩进、大小写统一之后，再去做diff，效率提升非常明显，特别是当一个SQL有几层嵌套子查询时，未经排版的SQL根本没法看清是哪里有问题。

这个经验在迁移审计时尤其有用。因为迁移项目一般要求提交SQL兼容性改造说明，如果改动前的SQL和改动后的SQL都是混乱的排版，评审的人看了只会头大。排版规范后，评审流程顺了很多。

4.5 数据校验：不能只看行数

数据迁移完成后，很多团队就简单统计一下行数，对上了就宣布迁移成功。这种方式非常危险。

我们当时的校验策略包含三层：

第一层，行数校验。对比源端和目标端每个表的行数。这个用脚本可以快速完成，但行数相同不代表数据一致。

第二层，抽样校验。对每张表抽取主键字段，通过主键关联，对比关键业务字段的值。注意要覆盖边界值：NULL值、空字符串、超大数值、特殊字符（如emoji）、时间字段的'0000-00-00'等特殊值。

第三层，业务校验。用几个核心业务流程在达梦环境上完整跑一遍，比如下单流程、报表查询流程、用户登录流程，分别验证写入和查询。

这里有一个非常特殊的校验场景：如果你迁移前没注意MySQL的sql_mode，导致源库里存在'0000-00-00'这类非法日期，那么到达梦后会直接插入失败或者报错。因为达梦的日期校验比MySQL严格。遇到这种情况，要在数据迁移前做一次数据清洗，把非法日期统一改成NULL或者有效的默认日期。

4.6 切换与回滚：不能被忽略的一环

切换方案的核心是：在切换窗口内，先做一次增量数据迁移（把上次全量迁移之后新产生的数据补上），然后停应用，再执行最后一次增量同步，最后把应用连接串切换到达梦库。

回滚方案则要提前准备好：在达梦环境验证失败的情况下，如何快速把应用切回MySQL。这里的关键是，MySQL原库在迁移期间不能被应用写入破坏掉。我的做法是给MySQL做一个只读账号，或者把原库的binlog保留，保证必要时可以回放。

另外，如果切换后应用端需要同时支撑读写，但达梦库并没有完全达标，可以考虑在应用层做读写分离，先让写入走达梦、读请求仍走MySQL的过渡方案，待稳定性验证后再全量切换。不过这要求代码层对数据源有较好的抽象，不是所有项目都能快速实现。

5. 迁移实施中容易忽略的"隐藏雷区"

前面的内容是大框架，这一节我想专门讲几个在迁移实施过程中容易忽略的小问题。这些问题如果不注意，完全可能在项目验收阶段跳出来给你一击。

5.1 驱动版本与连接URL参数

达梦JDBC驱动的版本选择会影响很多行为。老版本驱动可能不支持MySQL兼容模式的一些特性。连接URL建议加上compatibleMode=mysql这类参数（具体参数名随版本不同而有差异，以官方文档为准），有些环境还要配置zeroDateTimeBehavior=convertToNull，否则连到库里一旦出现'0000-00-00'日期，应用直接报错。

5.2 时间类型：datetime vs timestamp

MySQL中DATETIME和TIMESTAMP的行为有很大差异，前者范围大、不依赖时区，后者依赖时区且有2038年问题。到达梦后，这两种类型可能需要映射为TIMESTAMP或DATETIME（达梦也支持）。特别要注意时区处理：如果应用服务器和数据库服务器的时区不一致，迁移后时间字段可能出现8小时偏移。我们当时专门写了一个SQL，扫描所有时间字段并做一轮标准时区校准。

5.3 性能问题：慢SQL在达梦上可能更慢

迁移完成后，真正让人头疼的不是功能性问题，而是性能问题。MySQL中写得不错的SQL，到达梦上可能因为优化器行为不同而变得很慢。典型场景：

• LIKE '%keyword%'无法走索引，在MySQL和达梦中都一样，但如果数据量大，达梦的性能损失可能更明显。
• 达梦的统计信息是独立的，全量迁移完成后，一定要重新收集统计信息，否则优化器可能拿着空的统计信息生成灾难性的执行计划。

sql复制DBMS_STATS.GATHER_SCHEMA_STATS('YOUR_SCHEMA');

5.4 JDBC Batch批量写入：达梦对rewriteBatchedStatements的依赖

MySQL JDBC可以通过rewriteBatchedStatements=true让批量插入性能大幅提升。达梦JDBC对批量写入的支持方式不同，如果直接把MySQL JDBC的URL参数套用到达梦，某些参数达梦驱动根本不会识别，甚至报了连接错误。要格外注意区分哪些参数是MySQL驱动的专有行为。

5.5 保留字的隐藏攻击面

前面说过MODEL这类保留字，但在迁移实践中我发现，还有一类标识符特别容易踩雷：从业务表名字段名里带有系统或环境关键词的，比如user、order、group、index、comment、level。在MySQL中它们可能是非保留字或上下文关键词，但到达梦中可能就成了完全保留字。

所以我们迁移前的元数据扫描，不仅要把表名、字段名扫出来，还要把索引名、约束名、视图名、存储过程名、触发器名全部列出来，跟达梦的保留字列表做比对。命中保留字的，一律用双引号包裹或直接改名。这一步做在一个Excel宏里能快速搞定。

5.6 大小写敏感：库名表名字段名的"性格差异"

MySQL在Linux下的表名是大小写敏感的（取决于lower_case_table_names参数），而字段名和别名在MySQL中一般是大小写不敏感的。达梦则恰恰相反，达梦对标识符默认不区分大小写，但如果用双引号包裹了标识符，则变得大小写敏感。

这个特性带来的问题是：如果MySQL源库里的表名是User_Info，迁移到达梦后变成USER_INFO，而应用层SQL用的是user_info，那么能正常解析；但如果应用层SQL里用了双引号包裹"User_Info"，到达梦后反而找不到表，因为达梦根据双引号将它解析成了区分大小写的对象名。

结论是：迁移后建议统一规范标识符的大小写风格（推荐全大写或全小写），并减少在SQL中写双引号标识符，避免因大小写匹配问题引起的隐性错误。

6. 我踩过的最隐蔽的一个坑：兼容模式下MODEL报错与"DTS迁移后触发器/视图失效"

最后分享一个很少有人提到的问题。

我们的迁移项目里有一批MySQL视图，DTS工具把视图结构翻译到达梦后，部分视图在查询时直接报"无效的标识符"或"表或视图不存在"。检查后发现，视图本身创建成功了，但视图中引用的列名或表名如果带了反引号或做了大小写敏感处理，DTS迁移后对象的依赖关系就失效了。

比如MySQL中这样一个视图：

sql复制CREATE VIEW v_user_info AS
SELECT `id`, `name`, `dept_id` FROM `user_info` WHERE `status` = 1;

DTS转换到达梦后，可能生成的是：

sql复制CREATE VIEW v_user_info AS
SELECT "id", "name", "dept_id" FROM "user_info" WHERE "status" = 1;

如果达梦中实际的表名是小写user_info（在双引号模式下），而视图里引用的是全大写"user_info"，那么视图编译时找不到表，直接失效。

解决方法是：**视图迁移后，逐个执行ALTER VIEW xxx COMPILE;并查询USER_ERRORS或状态字段，找出所有失效对象，逐一手工修正。**这个工作看起来工作量不大，但如果不做，上线后一调用某个报表，发现整个报表模块全挂，那场面就不好看了。

另外，达梦的触发器迁移也同样有这个问题。DTS会把MySQL触发器翻译成达梦的CREATE TRIGGER语法，但触发器体中引用的表若没有被正确识别，同样会导致触发器状态异常。建议在数据迁移完成后，对全库做一次对象有效性检查：

sql复制SELECT OBJECT_NAME, OBJECT_TYPE, STATUS
FROM USER_OBJECTS
WHERE STATUS = 'INVALID';

把所有INVALID对象清理干净，才算是真正完成迁移。

如果你现在正准备做MySQL到达梦的迁移，我的核心建议是先别急着买服务器装库导数据，而是先在测试环境把SQL兼容性跑一遍，特别是那些用了LIMIT、反引号、GROUP_CONCAT、IFNULL、特殊别名的SQL，提前暴露问题。迁移方案上，尽量用"DTS全量 + 增量数据脚本 + 对象有效性校验 + 应用层SQL兼容矩阵回归"这套组合拳。最后，所有的工具、脚本、校验SQL、遗留问题清单，都要存档，因为迁移只是开始，后面的运维和优化才是真正考验团队的阶段。