MySQL到达梦数据库迁移实战：dexp/dimp命令行全流程指南

1. 项目概述：从MySQL到国产达梦的迁移之路

最近在帮一个项目做数据库国产化适配，核心任务就是把原有的MySQL数据库完整地迁移到达梦数据库上。这事儿听起来简单，不就是导数据嘛，但真动起手来，你会发现两个数据库在语法、数据类型、函数乃至一些核心设计理念上都有不少差异，直接用图形化工具或者简单的mysqldump导出再导入，大概率会报一堆错，根本跑不通。经过几轮折腾，我总结出了一套相对稳妥、可复现的纯命令行迁移方案，核心就是利用达梦数据库自带的dexp和dimp工具，配合一些预处理和适配工作。这套方法特别适合在服务器环境、CI/CD流水线或者需要批量处理的场景下使用，全程不依赖图形界面，稳定可控。如果你也面临类似的迁移需求，无论是为了满足信创要求，还是单纯的技术选型切换，这篇从实战中踩坑总结出来的全步骤指南，应该能帮你省下不少时间。

2. 迁移方案设计与核心工具解析

2.1 为什么选择 dexp/dimp 而非其他方式？

面对数据库迁移，常见的思路有几种：一是用第三方ETL或数据同步工具（如Kettle、DataX），二是用数据库自带的逻辑导出导入工具，三是通过JDBC/ODBC编写转换程序。对于MySQL到达梦的迁移，达梦官方提供了dts迁移工具，但它更偏向图形化交互，对于自动化部署和命令行环境并不友好。而dexp（达梦数据导出）和dimp（达梦数据导入）这对命令行工具，是达梦数据库底层dmfldr工具的封装，性能高效，功能直接，能精细控制导出/导入的对象（全库、模式、表级）和内容（仅结构、仅数据、或两者皆有）。

选择它的核心理由有三点：第一是原生支持，作为达梦的亲儿子工具，对达梦自身的数据格式、对象定义兼容性最好，避免了第三方工具可能存在的解析偏差。第二是灵活性，通过丰富的参数，可以轻松实现只导某个用户（模式）下的对象、排除特定表、或者只导出数据不导出约束等复杂场景。第三是易于集成，纯命令行的特性让它能无缝嵌入Shell脚本、Ansible剧本或Jenkins Pipeline中，实现自动化迁移，这是图形化工具难以比拟的优势。当然，它也不是万能的，其工作逻辑是“连接源库 -> 导出为达梦格式文件 -> 连接目标库导入”，所以需要你能同时连接源MySQL和目标达梦数据库。

2.2 迁移前关键准备工作清单

在敲下第一个导出命令之前，充分的准备能避免一半以上的错误。以下是我梳理的必做清单：

1. 环境与权限确认：

   • 源端（MySQL）：确保你拥有待迁移数据库（或表）的SELECT权限。如果需要迁移存储过程、函数、视图等对象定义，还需要SHOW VIEW和PROCESS权限。建议在MySQL中创建一个专门用于迁移的账号，权限最小化。
   • 目标端（达梦）：在达梦数据库中，提前创建好与MySQL数据库对应的模式（SCHEMA）。达梦的模式概念等同于MySQL的数据库。确保用于导入的达梦账号对该模式拥有CREATE TABLE、INSERT等足够权限。通常，将该模式授权给该用户即可。
   • 网络与驱动：确保执行迁移命令的机器（可能是中间跳板机）能够同时访问MySQL和达梦数据库的网络端口（默认3306和5236）。这是最关键也是最容易出错的一步。你需要将MySQL的JDBC驱动包（如mysql-connector-java-8.0.xx.jar）放置到达梦数据库安装目录下的/drivers/jdbc子目录中。否则，dexp工具在连接MySQL时会直接报错，提示找不到驱动。

2. 对象与数据评估：

   • 字符集：检查MySQL数据库的字符集（如utf8mb4）。达梦数据库的字符集通常在创建数据库实例时确定（如UTF-8或GB18030）。虽然dexp/dimp会进行转换，但对于复杂字符（如Emoji），建议先在测试环境验证。
   • 数据类型映射：这是迁移的技术核心。MySQL的TINYINT(1)通常被映射为达梦的BIT（布尔型），DATETIME精度处理，TEXT/BLOB类型的长宽限制等，都需要预先评估。一个实用的方法是，先在达梦中用dexp只导出表结构（FULL=N，ROWS=N），生成建表语句，仔细检查并手动修正不兼容的数据类型定义。
   • 特有对象处理：MySQL的自增列（AUTO_INCREMENT）在达梦中对应IDENTITY属性。迁移工具通常能自动转换。但像MySQL的ENUM、SET类型，达梦没有直接对应，可能需要转换为VARCHAR+约束，或拆分为关联表。存储过程、函数、触发器的语法差异更大，往往需要人工重写。

3. 制定回滚方案：任何数据迁移都必须有回滚计划。对于目标达梦库，在导入前，如果目标模式非空，应进行完整备份（同样可使用dexp）。或者，确保你有从源MySQL快速重新导出的能力。

3. 分步实操：从导出到导入的完整流程

3.1 第一步：使用 dexp 从 MySQL 导出数据

dexp工具位于达梦数据库安装目录的bin文件夹下。我们首先进行导出操作。以下是一个导出指定MySQL数据库中所有表结构和数据的命令示例：

./dexp USERID=test_user/test_password@mysql_host:3306?database=source_db FILE=mysql_export.dmp LOG=mysql_export.log DIRECTORY=/path/to/export_dir FULL=Y

参数逐项解析与避坑指南：

• USERID：连接字符串。格式为用户名/密码@主机:端口?参数。这里的database=source_db是关键，指定了要导出的MySQL数据库名。密码如果包含特殊字符，可能需要用引号包裹。
• FILE：导出的DMP文件名。dexp和dimp使用专用的二进制格式，效率高于纯SQL文本。
• LOG：导出过程的日志文件。务必指定，这是排查问题最重要的依据。
• DIRECTORY：导出文件存放的目录。需要确保执行命令的用户对该目录有写权限。
• FULL=Y：表示全库导出（包括所有表、视图、索引、约束等）。如果只想导特定模式（用户），可以用SCHEMAS=模式名1,模式名2。如果只想导特定的表，可以用TABLES=表名1,表名2。

注意：第一次连接MySQL时，很可能会报错“No suitable driver found for jdbc:mysql://...”。这几乎百分之百是因为MySQL的JDBC驱动jar包没有放到正确位置。请确认dmdbms/drivers/jdbc目录下存在对应的驱动文件。驱动版本建议与MySQL服务器版本匹配，MySQL 5.x 可用 5.1.x， MySQL 8.x 建议用 8.0.x。

更精细的控制参数：

• QUERY：用于导出表的部分数据。例如QUERY=\"WHERE create_time > '2023-01-01'\"。这个参数非常强大，可以实现增量迁移。
• COMPRESS：是否压缩导出文件（Y/N）。对于大数据量，开启压缩（COMPRESS=Y）可以显著减少磁盘占用和传输时间。
• PARALLEL：并行度。在多核CPU环境下，设置PARALLEL=4之类的值可以加速导出，但可能会增加源库负载。
• ROWS：是否导出数据行。ROWS=Y（默认）导出数据和结构；ROWS=N则只导出表结构。在首次迁移时，我强烈建议先执行一次ROWS=N的导出，将生成的DMP文件用dimp的SQL_FILE参数转换为SQL脚本，审阅其中的对象创建语句，提前发现数据类型不兼容等问题。

3.2 第二步：在达梦端进行必要的适配与预处理

拿到导出的DMP文件后，不要急着导入。先到达梦数据库端，为目标导入做好准备。

1. 创建目标模式与用户：

   -- 使用达梦的管理工具（如disql）连接数据库 -- 创建与MySQL数据库同名的模式（如果不存在） CREATE SCHEMA IF NOT EXISTS target_schema; -- 创建用于导入的用户（如果不存在），并授权 CREATE USER imp_user IDENTIFIED by "YourPassword123"; GRANT RESOURCE, VTI TO imp_user; -- 将目标模式的权限授予该用户 GRANT CREATE TABLE, CREATE VIEW, CREATE INDEX, CREATE PROCEDURE ON SCHEMA target_schema TO imp_user;

2. 审阅并转换对象定义（可选但推荐）： 使用dimp工具的SQL_FILE参数，将DMP文件中的对象定义转换为SQL脚本，便于审查。

   ./dimp USERID=sysdba/SYSDBA@localhost:5236 FILE=mysql_export.dmp LOG=sql_gen.log DIRECTORY=/tmp SQL_FILE=review.sql

   执行后，会在/tmp目录下生成review.sql文件。用文本编辑器打开，重点检查：

   • 表结构：CREATE TABLE语句中的数据类型是否合适。例如，检查TEXT类型是否被正确映射，DATETIME的精度。
   • 约束与索引：检查外键约束名、索引名是否因超长被截断（达梦有对象名长度限制）。
   • 自增列：确认AUTO_INCREMENT是否已转换为IDENTITY(1,1)。

   对于发现的问题，可以手动编辑这个SQL脚本，然后在达梦库中直接执行修正后的脚本来创建空表结构，后续导入数据时使用dimp的TABLE_EXISTS_ACTION参数。

3.3 第三步：使用 dimp 导入到达梦数据库

准备工作就绪后，开始正式导入。这是最关键的一步。

./dimp USERID=imp_user/YourPassword123@localhost:5236 FILE=mysql_export.dmp LOG=dm_import.log DIRECTORY=/path/to/export_dir FULL=Y TABLE_EXISTS_ACTION=TRUNCATE

核心参数深度解析：

• USERID：连接目标达梦数据库的用户。该用户需拥有前面授予的权限。
• FILE,LOG,DIRECTORY：与dexp对应，指向导出文件和日志。
• FULL=Y：对应全库导入。如果导出时用了SCHEMAS或TABLES，这里也需要保持一致。
• TABLE_EXISTS_ACTION：这个参数至关重要，决定了当目标表已存在时的行为。
  • SKIP：跳过已存在的表。可能导致数据不全。
  • APPEND：向已存在的表追加数据。要求表结构完全一致。
  • TRUNCATE：先清空已存在表中的数据，再插入。这是最常用且安全的选项，确保导入的数据是全新的。
  • REPLACE：删除已存在的表，然后重新创建并插入。风险较高，可能破坏已有的关联对象。
• COMMIT_ROWS：指定每插入多少行提交一次事务。默认可能为5000。对于超大数据量的导入，可以适当调大（如50000）以减少事务开销，提升性能。但也要考虑回滚段的大小，如果单次提交数据量太大导致回滚段不足，会导入失败。
• FEEDBACK：每处理多少条记录显示一个进度点。例如FEEDBACK=1000，每处理1000行显示一个“.”，让你知道程序在运行。
• PARALLEL：与dexp类似，设置并行导入任务数，加速大数据表导入。

导入过程中的监控： 导入时，务必通过tail -f dm_import.log实时查看日志。重点关注是否有“错误”或“警告”。常见的警告可能包括“对象XXX已存在，跳过创建”，这通常是正常的。但出现“数据类型不匹配”、“违反唯一约束”等错误时，就需要暂停并分析。

3.4 第四步：后置验证与数据一致性检查

导入完成后，显示“导入成功”并不代表万事大吉，必须进行验证。

1. 对象数量对比：分别在MySQL和达梦库中，查询表、视图、存储过程等关键对象的数量，确保一致。

   -- MySQL SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'source_db'; -- 达梦 SELECT COUNT(*) FROM dba_tables WHERE owner = 'TARGET_SCHEMA';

2. 数据量（行数）对比：对核心大表或所有表，进行行数比对。可以编写脚本自动化完成。

   -- 生成MySQL行数查询语句（示例） SELECT CONCAT('SELECT \"', TABLE_NAME, '\", COUNT(*) FROM ', TABLE_NAME, ' UNION ALL') FROM information_schema.tables WHERE table_schema = 'source_db' ORDER BY TABLE_NAME; -- 将生成的查询分别在两个库执行，对比结果。

3. 抽样数据内容对比：随机抽取几张表，检查关键字段的数据内容、格式是否正确。特别是时间字段、数值精度、中文乱码等问题。

4. 业务功能验证：如果可能，将应用程序的连接串指向新的达梦数据库，进行核心业务流程的冒烟测试，这是最有效的验收方式。

4. 常见问题排查与实战技巧

4.1 连接类错误与解决方法

• 问题：dexp连接MySQL失败，报“No suitable driver found”或“通信链路失败”。

  • 排查：首先确认drivers/jdbc目录下的MySQL驱动jar包是否存在且版本匹配。其次，检查连接字符串格式是否正确，特别是主机、端口、数据库名。可以使用telnet mysql_host 3306测试网络连通性。
  • 解决：放置正确的驱动包。对于网络问题，检查防火墙规则。连接字符串可尝试简化为USERID=user/pass@host:port/dbname格式。

• 问题：dimp连接达梦失败，报“用户名或密码错误”或“没有[数据库名]的登录权限”。

  • 排查：确认达梦数据库实例已启动。确认用户名、密码、端口号正确。确认该用户是否被授予了RESOURCE和VTI角色（对于导入操作通常是必须的）。
  • 解决：使用系统管理员SYSDBA账号登录测试。检查达梦的dm.ini配置文件中的PORT_NUM参数确认端口。

4.2 对象与数据导入错误

• 问题：导入时报“违反唯一约束”或“主键冲突”。

  • 原因：通常是目标表中已存在数据，且TABLE_EXISTS_ACTION参数设置为了APPEND，而源数据和现有数据主键重复。
  • 解决：将TABLE_EXISTS_ACTION改为TRUNCATE，先清空再导入。或者在导入前手动TRUNCATE目标表。

• 问题：导入时报“数据类型转换错误”，例如将字符串转换到数值类型失败。

  • 原因：MySQL中某些字段可能存储了非纯数字的字符串（如‘N/A’，‘-’），而达梦对应字段定义为数值型。
  • 解决：这是数据清洗问题。需要在迁移前，在MySQL端处理这些脏数据。或者，在导出时使用QUERY参数过滤掉有问题的数据行，待后续单独处理。更彻底的办法是，修改达梦端的表结构，先将该字段定义为VARCHAR，导入后再在达梦中进行数据清洗和转换。

• 问题：表或视图创建失败，提示“对象名已存在”。

  • 原因：达梦中可能已经存在同名的对象。
  • 解决：如果确定要替换，可以在导入前手动删除达梦中的冲突对象。或者，使用dimp的IGNORE=Y参数忽略创建错误（但需谨慎，可能导致依赖关系混乱）。

4.3 性能优化与实战心得

1. 大表迁移策略：对于单表数据量过亿的超大表，不建议一次性导出导入。可以结合QUERY参数，按时间范围（如按月）分批导出导入。例如，QUERY=\"WHERE order_date BETWEEN '2023-01-01' AND '2023-01-31'\"。这样不仅降低单次操作风险，也便于分步验证。

2. 调整事务提交频率：默认的COMMIT_ROWS可能不适合所有场景。对于数据一致性要求极高、且导入过程可能中断的场景，可以设置较小的值（如1000），牺牲一些性能换取更细的断点。对于只追加历史数据、不易出错的大批量导入，可以调大到几万甚至十万，能显著提升速度。务必监控达梦数据库的回滚段使用情况。

3. 善用日志与错误文件：dimp除了生成LOG文件，如果指定了BADFILE参数，还会将导入失败的数据行记录到指定文件。例如BADFILE=import_bad.bad。导入完成后，检查这个.bad文件，它能精准定位是哪一行数据的哪个字段出了问题，是修复数据的直接依据。

4. 先结构，后数据：对于复杂的迁移，最稳妥的流程是：a) 用dexp只导出结构 (ROWS=N)。b) 用dimp的SQL_FILE生成脚本并人工审核、修正。c) 在达梦中执行修正后的脚本创建所有对象。d) 最后，再次使用dexp只导出数据 (CONTENT=DATA_ONLY)，并用dimp以TABLE_EXISTS_ACTION=APPEND方式导入。这样做虽然步骤多，但可控性最强。

5. 字符集陷阱：如果导入后出现中文乱码，不要只盯着达梦的数据库字符集。请检查：1) 源MySQL表的字符集。2)dexp导出时客户端的字符集环境（可通过设置NLS_LANG环境变量影响）。3) 目标达梦数据库的字符集。确保整个链路字符集兼容，最好统一为UTF-8或GB18030。可以在导出和导入命令前，临时设置环境变量export LANG=en_US.UTF-8(Linux) 来规范环境。