MySQL到达梦数据库命令行迁移全流程：从环境准备到性能调优实战

1. 项目缘起：为什么选择命令行进行数据库迁移？

最近接手了一个老项目的数据库升级任务，需要将原本运行在MySQL 5.7上的业务系统，完整迁移到国产的达梦数据库8（DM8）。在评估了各种图形化迁移工具后，我最终还是决定采用命令行方式来完成这次迁移。你可能会问，现在各种DTS工具、ETL平台那么方便，为什么还要“复古”地用命令行呢？这背后有几个很实际的考量。

首先，可控性是命令行方式最大的优势。图形化工具虽然点几下鼠标就能开始，但它背后执行的SQL语句、转换规则、错误处理逻辑对你来说是个黑盒。一旦迁移过程中出现字符集乱码、数据类型映射错误或者约束丢失，你很难快速定位问题根源。而命令行迁移，每一步操作都是你自己写下的命令，从数据导出、格式转换到数据导入，整个链路清晰可见，任何报错都能追溯到具体的命令和参数，排查效率极高。

其次，可重复与自动化。这次迁移可能只是开始，后续或许还有测试环境、预生产环境的多次同步。通过编写Shell脚本或批处理文件，将整个迁移流程固化下来，下次只需要修改一下连接参数就能一键执行，避免了在图形界面重复点击的繁琐和人为失误。这对于需要频繁构建和刷新环境的DevOps流程来说，是刚需。

再者，对复杂场景的适应能力。我们的数据库里有几十张表，包含空间地理信息（GIS）、大文本字段（TEXT）和自增主键。一些通用迁移工具对MySQL特有的函数（如GROUP_CONCAT）或达梦不直接支持的数据类型处理得并不好。命令行迁移允许我在中间环节，对导出的SQL或数据文件进行精细化的清洗、转换和校对，比如用sed或Python脚本批量修改建表语句，这种灵活性是图形工具难以提供的。

当然，这条路并不轻松，需要同时对MySQL和达梦数据库的客户端工具、SQL语法差异有深入的了解。但走通之后，你会对两种数据库的“脾气”都摸得一清二楚。接下来，我就把这次从MySQL到达梦的命令行迁移全步骤，包括踩过的坑和总结的技巧，毫无保留地分享出来。

2. 迁移前哨战：环境准备与核心工具盘点

工欲善其事，必先利其器。命令行迁移的核心，在于几个关键的命令行工具。这一步没准备好，后面会步步维艰。

2.1 工具链准备：MySQL与达梦的“左膀右臂”

迁移的本质是数据的导出和导入，因此你需要两套客户端工具：

1. MySQL客户端工具集：主要使用mysqldump进行数据导出。这是MySQL官方自带的逻辑备份工具，绝大多数Linux发行版在安装mysql-client包后都会包含，Windows版MySQL安装程序也会提供。确保你使用的mysqldump版本与源数据库版本兼容，建议使用与MySQL服务器相同或更高版本的工具。
2. 达梦数据库客户端工具集：主要使用dimp和disql工具。dimp是达梦的数据导入工具，disql是其命令行交互工具，相当于MySQL的mysql命令行客户端。这些工具包含在达梦数据库的安装包中。关键点：请务必从达梦官网下载与你的目标达梦数据库版本完全一致的客户端工具包。版本不匹配是导致“no default drivers found”或连接失败的常见原因。

我的踩坑记录：最初我图省事，在服务器A上安装了达梦数据库，然后试图从服务器B上使用A的客户端工具连接，结果频繁报错。后来才明白，最佳实践是在执行迁移操作的机器上（比如你的运维跳板机或本地开发机），同时安装MySQL客户端和达梦数据库的完整客户端（而不仅仅是JDBC驱动）。这样，所有命令都在同一环境执行，避免网络和库依赖的干扰。

2.2 网络与权限检查：打通任督二脉

在开始之前，必须确保命令行环境能畅通地访问源库和目标库。

• 访问MySQL源库：在迁移执行机上，使用mysql -h [mysql_host] -P [port] -u [username] -p命令尝试登录。除了检查连通性，更要确认你使用的账号拥有足够的权限。对于mysqldump，需要SELECT（查询数据）、SHOW VIEW（查看视图）、TRIGGER（导出触发器）以及LOCK TABLES（如果使用--single-transaction则不需要）等权限。一个简单的检查方法是尝试用该账号执行SHOW DATABASES;和USE [your_database]; SHOW TABLES;。
• 访问达梦目标库：同样，使用达梦的disql工具进行登录测试：disql [username]/[password]@[dm_host]:[port]。达梦数据库默认端口是5236。这里常见的坑是防火墙。务必检查迁移执行机与达梦服务器之间的5236端口是否开放。在Linux上可以用telnet dm_host 5236或nc -zv dm_host 5236测试。

注意：达梦数据库的默认用户SYSDBA权限很大，但生产环境建议为迁移专门创建一个用户，并授予目标模式（类比MySQL的数据库）的CREATE TABLE、INSERT、INDEX等权限。使用最小权限原则是安全运维的好习惯。

2.3 创建目标模式与评估兼容性

在达梦数据库中，SCHEMA（模式）的概念类似于MySQL的DATABASE。迁移前，需要在达梦库中创建一个空模式来接收数据。

-- 使用disql登录后执行 CREATE SCHEMA `your_target_schema` AUTHORIZATION `your_migration_user`;

接下来，进行一轮快速的兼容性评估。手动选取几张结构有代表性的表（包含自增列、时间类型、枚举类型、文本字段等），用mysqldump仅导出结构（--no-data），然后到达梦库中尝试执行。这一步能提前发现大部分语法不兼容问题，例如：

• 自增列：MySQL的AUTO_INCREMENT在达梦中是IDENTITY(1,1)。
• 时间戳：MySQL的TIMESTAMP默认值CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP在达梦中有不同的实现方式。
• 字符串类型：VARCHAR(255)在MySQL和达梦中都是有效的，但达梦对字符集（如utf8mb4）的支持可能需要确认。
• 注释语法：两者都支持COMMENT，但导出语句可能需要微调。

把这些问题记录下来，我们会在数据导出阶段通过脚本进行批量处理。

3. 核心迁移流程：从MySQL导出到达梦导入

这是整个迁移过程最核心的环节，我将其分解为“导出-转换-导入”三个子步骤。

3.1 第一步：使用mysqldump导出结构与数据

mysqldump的参数有上百个，但用于迁移，以下几个组合拳至关重要：

# 基础导出命令示例 mysqldump -h [mysql_host] -P 3306 -u [username] -p[password] \ --databases [your_database] \ --single-transaction \ --master-data=2 \ --routines \ --events \ --triggers \ --hex-blob \ --complete-insert \ --default-character-set=utf8mb4 \ --result-file=./mysql_full_backup.sql

关键参数解读与避坑指南：

• --single-transaction：在事务中执行导出，确保得到一个一致性的数据快照，对InnoDB表非常重要。如果表都是MyISAM引擎，则不能使用此参数，需改用--lock-all-tables。
• --master-data=2&--routines&--events&--triggers：分别记录binlog位置（用于未来增量同步）、导出存储过程/函数、导出事件、导出触发器。确保你的迁移是完整的。
• --hex-blob：将BLOB类型（如图片、二进制文件）的数据以十六进制格式导出。这是必须项！否则，二进制数据在导出文件中可能被当作字符串处理，导致导入达梦时数据损坏或乱码。
• --complete-insert：生成包含列名的完整INSERT语句。这虽然会让文件变大，但在源表和目标表结构不完全一致（如列顺序不同）时，能极大提高导入的准确性和容错性。
• --default-character-set=utf8mb4：明确指定导出文件的字符集为utf8mb4（MySQL中支持4字节UTF-8的字符集）。这能避免因默认字符集不同导致的乱码问题。务必与你的数据库实际字符集保持一致。

导出后的文件检查：用文本编辑器打开导出的.sql文件头部，你应该能看到SET语句设置了字符集、以及以--开头的注释信息。快速搜索一下CREATE TABLE语句和INSERT INTO语句，确认数据都在。

3.2 第二步：SQL文件转换与清洗

直接拿mysqldump导出的文件给达梦的dimp导入，十有八九会失败。因为两者的SQL方言存在差异。我们需要一个转换清洗的步骤。我强烈建议不要直接修改原备份文件，而是通过脚本生成一个新的、适配达梦的SQL文件。

转换主要针对以下几个方面，我写了一个简单的Python脚本示例来处理：

import re import sys def convert_mysql_to_dm(sql_content): # 1. 替换引擎声明 (如果存在) sql_content = re.sub(r'ENGINE=InnoDB', '', sql_content, flags=re.IGNORECASE) sql_content = re.sub(r'ENGINE=MyISAM', '', sql_content, flags=re.IGNORECASE) # 2. 替换自增列语法 AUTO_INCREMENT -> IDENTITY(1,1) # 注意：需要更精确的匹配，避免误伤字符串内容。这里是一个简化示例。 # 更稳健的做法是使用SQL解析库，但对于大多数情况，正则可以应对。 sql_content = re.sub(r'AUTO_INCREMENT', 'IDENTITY(1,1)', sql_content, flags=re.IGNORECASE) # 3. 处理 ` 反引号（MySQL用于引用标识符，达梦通常用双引号或不需要） # 达梦通常不支持反引号，直接移除或替换为双引号。移除更安全。 sql_content = sql_content.replace('`', '') # 4. 处理特定的默认值，如 CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP # 达梦不支持 ON UPDATE，可能需要创建触发器来实现。这里先简单替换为 CURRENT_TIMESTAMP。 sql_content = re.sub(r'CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP', 'CURRENT_TIMESTAMP', sql_content, flags=re.IGNORECASE) # 5. 注释语法检查：MySQL的 COMMENT '注释' 语法达梦也支持，通常无需修改。 # 但需注意单引号转义问题，上述替换已移除反引号，一般无影响。 # 6. 非常重要：将文件开头的 /*!... */ 等MySQL特定注释或执行条件移除，它们会干扰达梦。 # 删除 /*!40101 SET ... */ 等 sql_content = re.sub(r'/\*!\d+.*?\*/', '', sql_content, flags=re.DOTALL) # 7. 修改 DELIMITER 语句（用于存储过程/触发器），达梦可能不支持，或语法不同。 # 一个简单粗暴但有效的方法：注释掉 DELIMITER 相关行，并确保过程体中的分号正确。 lines = sql_content.split('\n') new_lines = [] in_routine_body = False for line in lines: if line.strip().upper().startswith('DELIMITER'): # 忽略DELIMITER行 continue # 简单判断是否进入过程/函数/触发器定义体 if re.search(r'^(CREATE|ALTER)\s+(PROCEDURE|FUNCTION|TRIGGER)', line, re.IGNORECASE): in_routine_body = True elif in_routine_body and line.strip() == 'END': in_routine_body = False new_lines.append(line) sql_content = '\n'.join(new_lines) return sql_content if __name__ == '__main__': if len(sys.argv) != 3: print("Usage: python convert.py <input_mysql.sql> <output_dm.sql>") sys.exit(1) input_file = sys.argv[1] output_file = sys.argv[2] with open(input_file, 'r', encoding='utf-8') as f: mysql_sql = f.read() dm_sql = convert_mysql_to_dm(mysql_sql) with open(output_file, 'w', encoding='utf-8') as f: f.write(dm_sql) print(f"Conversion completed. Output file: {output_file}")

重要提醒：这个脚本是一个起点，并非万能。对于复杂的存储过程、自定义函数或特殊的索引定义，可能需要手动调整。务必在导入前，用disql工具对转换后的关键建表语句进行预执行测试。

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

清洗转换后的SQL文件，理论上可以通过达梦的disql命令行工具直接执行。但对于超大型文件（几个GB以上），disql执行效率可能不高，且错误恢复麻烦。这里推荐使用达梦专用的数据导入工具dimp。

dimp支持导入由dexp（达梦导出工具）或mysqldump（经过一定处理）生成的文本文件。但更常见的做法是，我们先用disql执行转换后的DDL（建表、索引等结构文件），再用dimp只导入数据。

首先，导入数据库结构：

# 使用disql执行转换后的SQL文件中的DDL部分（可以先手动分离出纯DDL部分，或使用工具过滤出CREATE语句） disql [username]/[password]@[dm_host]:5236 `./converted_ddl_part.sql`

如果文件很大，可以尝试在disql内使用start命令：start /path/to/converted_ddl_part.sql。

然后，准备数据文件并导入：dimp需要数据文件是特定的格式。一个更实用的方法是：利用mysqldump的-T参数，将数据导出为纯文本格式（如CSV），然后使用dimp的TABLE_IMPORT模式导入。

1. 使用mysqldump导出CSV格式数据：

   mysqldump -h [mysql_host] -u [username] -p[password] [your_database] [table_name] \ --fields-terminated-by=',' \ --fields-enclosed-by='\"' \ --lines-terminated-by='\\n' \ --tab=/path/to/output/dir \ --no-create-info

   这会在指定目录下为[table_name]生成一个.sql文件（表结构，可忽略）和一个.txt文件（数据）。你需要为每张表执行此操作，或写循环脚本。

2. 使用dimp导入CSV数据： 首先，需要创建一个dimp的控制文件（例如import.ctl），指定导入规则：

   # import.ctl USERID=your_migration_user/your_password@dm_host:5236 FILE=/path/to/output/dir/table_name.txt TABLE=your_target_schema.table_name LOG=/path/to/import_table_name.log BAD=/path/to/import_table_name.bad ERRORS=1000000 DIRECT=TRUE SKIP=0

   然后执行导入：

   dimp CONTROL=import.ctl

我的经验：对于数据量不大的迁移（几十GB以内），直接使用转换后的完整SQL文件通过disql执行，可能是最快捷的方式，因为省去了拆分的步骤。但对于海量数据，特别是单表上亿行，强烈建议采用CSV导出+dimp导入的方式，并启用DIRECT=TRUE（直接路径加载）以提升性能。无论哪种方式，务必分表进行，并记录每张表的导入日志，这样当某张表导入失败时，可以快速定位和重试，而不影响整体进度。

4. 迁移后的关键验证与性能调优

数据导入成功，并不代表迁移工作结束。以下验证步骤至关重要，它们能帮你发现那些“静默”的错误。

4.1 数据一致性校验：确保颗粒归仓

这是最核心的验证环节，目标是确认源库和目标库的数据记录在数量和质量上完全一致。

1. 记录数比对：这是最基本的检查。为每个表执行计数。

   • MySQL端：SELECT COUNT(*) FROM your_database.table_name;
   • 达梦端：SELECT COUNT(*) FROM your_target_schema.table_name;将结果记录到表格中比对。对于分区表，需要按分区进行比对。

2. 抽样内容比对：计数相同不代表数据相同。需要抽样检查。

   • 随机抽样：在MySQL端随机抽取N条（比如1000条）记录的主键ID，然后分别在两边查询这些ID对应的所有字段，进行逐字段比对。
   • 哈希校验（推荐）：对于大数据量表，逐条比对不现实。可以采用哈希聚合的方式。例如，在MySQL和达梦端分别执行：

     -- 假设有主键id和更新时间update_time SELECT COUNT(*) as cnt, SUM(CAST(CONV(SUBSTRING(MD5(CONCAT_WS('|', col1, col2, col3)), 1, 16), 16, 10) AS UNSIGNED)) as hash_sum FROM table_name;

     这条SQL计算了总行数和一个基于多个字段拼接后的MD5哈希值的和（取前16位转数字）。如果两边的cnt和hash_sum都一致，那么数据一致性就有极高的可信度。注意：达梦的MD5函数可能是HASH_MD5，且字符串拼接函数是||或CONCAT，需要根据达梦语法调整上述SQL。

3. 特殊字段检查：重点检查以下容易出错的字段：

   • 二进制数据（BLOB）：抽取几条包含BLOB字段的记录，在两端分别将字段值导出为文件，然后用md5sum或diff工具比较文件是否一致。
   • 时间日期字段：检查时区转换是否正确。确保DATETIME、TIMESTAMP的值在迁移后没有发生意外的偏移。
   • 数值精度：检查DECIMAL、FLOAT/DOUBLE类型的数据，精度是否保持。
   • 字符编码：检查中文字符、特殊符号（如Emoji，如果源库是utf8mb4）是否显示正常，无乱码。

4.2 对象与约束完整性检查：骨架不能散

数据对了，数据库的“骨架”——各种对象和约束也要完整。

1. 索引检查：对比源库和目标库每张表的索引数量、索引名称、索引类型（唯一、普通等）和包含的列是否一致。达梦的索引命名可能与MySQL自动生成的不同，但类型和列应该对应。
2. 主键与外键约束：确认所有主键约束、外键约束都已正确创建并生效。可以尝试向子表插入一条违反外键约束的数据，看是否会报错。
3. 存储过程、函数、触发器：这是重灾区。需要逐个执行验证。编写简单的测试脚本，调用存储过程或函数，传入边界值，对比输出结果是否与MySQL端一致。触发器的验证更繁琐，需要在相关表上执行INSERT、UPDATE、DELETE操作，观察触发器是否按预期触发并执行了正确的逻辑。
4. 视图：执行SELECT * FROM view_name LIMIT 5;，检查视图是否能正常查询，并且结果符合预期。对比视图的定义语句，确保在达梦中语义一致。

4.3 性能基准测试与初步调优

数据库迁移后，同样的SQL语句执行效率可能天差地别。必须进行性能验证。

1. 核心查询对比：从业务系统中找出10-20个最核心、最频繁或最复杂的SQL查询。分别在迁移前后的数据库上执行，记录执行时间、扫描行数等关键指标。可以使用EXPLAIN（MySQL）和EXPLAIN/EXPLAIN PLAN FOR（达梦）来对比执行计划。
2. 达梦特有的性能调优点：
   • INI参数调整：达梦通过dm.ini配置文件管理大量参数。迁移后，可能需要根据新的数据量和访问模式调整BUFFER（缓冲区）、MAX_SESSIONS（最大会话数）等参数。不要盲目复制生产环境的配置，建议从默认值开始，根据监控逐步调整。
   • 统计信息更新：数据导入后，达梦的优化器需要准确的统计信息来生成好的执行计划。立即对全库或核心大表执行统计信息收集：

     DBMS_STATS.GATHER_TABLE_STATS('YOUR_TARGET_SCHEMA', 'TABLE_NAME');

   • 索引优化：对比MySQL的执行计划，看是否有些查询在达梦上走了全表扫描，而在MySQL上使用了索引。可能需要根据达梦的优化器特性，创建新的索引或调整复合索引的列顺序。达梦对函数索引、表达式索引的支持与MySQL不同，需要留意。

迁移后的系统需要在测试环境进行一段时间的全链路压测，模拟真实流量，观察应用日志和数据库监控，确保稳定无误后才能考虑切换上线。

5. 常见故障排查与解决方案实录

在整个迁移过程中，我遇到了不少报错。这里把几个最具代表性的问题及其解决思路记录下来，希望能帮你少走弯路。

5.1 连接类错误：“连接数据库失败”与“no default drivers found”

这是最初阶，也最让人头疼的问题。

• 问题现象：执行disql或dimp命令时，提示“连接数据库失败”，或更具体的“no default drivers found”。
• 排查思路：
  1. 网络与端口：这是首要怀疑对象。在迁移执行机上使用telnet [dm_host] 5236测试端口通不通。如果不通，检查达梦服务器防火墙（Linux的firewalld/iptables，Windows的防火墙）、安全组规则是否放行了5236端口。
  2. 达梦服务状态：到达梦服务器上，使用systemctl status DmServiceXXX（Linux）或查看服务管理面板（Windows），确认数据库实例服务是否正在运行。
  3. 客户端工具版本：极其重要！确保你使用的disql、dimp等命令行工具与目标达梦数据库的版本完全一致。从官网下载对应版本的“客户端驱动”包进行安装。版本不匹配是导致“no default drivers found”的常见原因。
  4. 连接字符串格式：disql的连接格式是username/password@host:port。注意密码中如果包含特殊字符（如@、:），可能需要用转义或引号包裹。可以尝试先用一个简单密码的测试用户连接，排除密码复杂性问题。
  5. 环境变量：Linux下，确保达梦客户端的bin目录（如/opt/dmdbms/bin）已加入PATH环境变量，并且LD_LIBRARY_PATH环境变量包含了达梦的库文件目录（如/opt/dmdbms/bin）。Windows下，检查安装后是否自动配置了系统路径。

5.2 SQL语法与执行错误：来自mysqldump文件的“惊喜”

转换后的SQL文件在执行时，可能会遇到各种语法错误。

• 问题现象：在disql中执行SQL文件，在某一处报错停止，错误可能关于“无效的SQL语句”、“缺少关键字”、“标识符无效”等。
• 排查与解决：
  1. 定位错误行：错误信息通常会给出行号。用文本编辑器打开SQL文件，跳转到对应行附近。
  2. 常见语法冲突点：
     • **反引号()**：MySQL使用反引号引用表名、列名，达梦通常使用双引号或不使用（如果标识符不含特殊字符）。我们的清洗脚本已经移除了反引号，但如果标识符本身是达梦的保留字（如USER、LEVEL），移除反引号后可能导致语法错误。这时需要将其用双引号括起来："USER"`。
     • AUTO_INCREMENT：必须替换为IDENTITY(1,1)。检查清洗脚本是否漏掉了某些在注释或字符串中的AUTO_INCREMENT（虽然少见）。
     • 特定的MySQL函数或语法：如GROUP_CONCAT、ON DUPLICATE KEY UPDATE、LIMIT（达梦用TOP或ROWNUM）等。这些在清洗脚本中可能没有处理。遇到时，需要评估是否必须使用。如果是，则需寻找达梦的等价实现（如用LISTAGG替代GROUP_CONCAT）或重写业务逻辑。
     • 存储过程/函数中的DELIMITER：如之前脚本所示，DELIMITER是MySQL客户端特有的命令，达梦的disql不认识。需要将其移除，并确保过程体内部的分号能正确解析。有时需要手动调整过程体的格式。
  3. 分段执行与调试：不要一次性执行整个巨大的SQL文件。可以将其按表拆分成多个小文件，或者使用split命令按行拆分。然后逐个文件执行，这样能快速定位是哪张表或哪个对象的定义出了问题。

5.3 数据导入错误：字符集与数据截断

数据导入阶段，可能会遇到乱码或数据无法插入的问题。

• 问题现象：dimp导入时报告“无效的字节序列”或“值太大无法放入列”。
• 排查与解决：
  1. 字符集不一致：这是乱码的根源。确保整个链路字符集统一：
     • 源MySQL数据库字符集（show variables like 'character_set_database';）。
     • mysqldump导出时指定的--default-character-set参数（我们之前设为utf8mb4）。
     • 达梦数据库的数据库字符集（创建数据库时指定，或在dm.ini中配置）。达梦应使用UTF-8或GB18030等兼容字符集。
     • 迁移执行机操作系统的终端或脚本文件的编码（建议统一为UTF-8）。 在任何环节出现字符集转换都可能导致乱码。如果发现乱码，可以尝试在dimp控制文件中指定字符集参数CHARACTER_CODE = 'UTF8'。
  2. 数据截断：“值太大无法放入列”通常是因为达梦中对应列的长度或精度定义小于MySQL。例如，MySQL中VARCHAR(500)，但转换时可能被误处理或达梦有不同限制。需要检查并修正目标表的DDL，确保其列定义能容纳源数据。特别是对于TEXT、BLOB等大对象类型，达梦有CLOB、BLOB对应，但需要注意其初始化参数设置。
  3. 日期格式不匹配：如果数据文件是CSV格式，日期字段的字符串格式（如YYYY-MM-DD HH:MI:SS）必须与达梦数据库的日期格式参数匹配。可以在dimp控制文件中使用DATE_FORMAT参数指定，或者在导入前使用disql设置会话参数：ALTER SESSION SET NLS_DATE_FORMAT = 'YYYY-MM-DD HH24:MI:SS';。

5.4 性能问题：导入速度慢或导入后查询慢

• 导入慢：

  • 关闭约束和索引：在导入大量数据前，可以先禁用目标表的外键约束和非唯一索引，导入完成后再重新启用和创建。这能大幅提升导入速度。
  • 使用dimp的DIRECT模式：如前所述，在dimp控制文件中设置DIRECT=TRUE，使用直接路径加载，绕过SQL层和部分缓存机制。
  • 调整提交频率：dimp的COMMIT_ROWS参数控制多少行提交一次。对于海量数据，适当增大该值（如设置为10000），减少提交次数，可以提升性能。但要注意，值太大会占用大量回滚段空间。
  • 并行导入：如果服务器资源充足，可以将大表拆分成多个文件，使用多个dimp进程并行导入不同的表。

• 导入后查询慢：

  • 更新统计信息：这是首要操作！数据导入后，表的行数分布已发生巨变，旧的或空的统计信息会导致优化器选择错误的执行计划。立即对全库或核心表执行DBMS_STATS.GATHER_TABLE_STATS。
  • 检查执行计划：对慢查询使用EXPLAIN，对比MySQL和达梦的执行计划。重点关注是否缺少了关键的索引，或者达梦选择了一个低效的索引。
  • 达梦INI参数：检查dm.ini中的内存相关参数，如BUFFER、MAX_BUFFER。数据量增大后，可能需要适当调大缓冲区大小，让更多热数据留在内存中。

整个命令行迁移过程，就像一场精密的外科手术，需要耐心、细致和对两种数据库的深刻理解。它没有图形化工具的一键式便捷，但却给了你最大的掌控力和问题排查能力。当你看到所有数据准确无误地在达梦数据库中跑起来，并且性能达标时，那种成就感是无可替代的。这份全步骤指南和踩坑记录，希望能成为你手术台旁的那份可靠图谱。