达梦→mysql迁移必须手动建表，dts仅导入数据不生成结构；需提前导出元信息对照类型映射、处理clob/字符集/大小写敏感等兼容性问题，并禁用外键约束，命令行模式更稳定可控。
达梦 → MySQL 迁移必须手动建表，DTS不自动生成目标结构
DTS 从达梦迁出到 MySQL 时，DTS 工具本身不支持自动创建 MySQL 表结构——它只负责把已有数据灌进去。如果目标库没提前建好表，会直接报错 Table 'xxx' doesn't exist。
- 必须先用达梦的
SELECT * FROM USER_TAB_COLUMNS或DBA_TAB_COLUMNS导出字段名、类型、长度、是否为空等元信息 - 人工对照达梦→MySQL 类型映射表转换：比如
DECIMAL(p,s)对应DECIMAL(p,s)，DATE保持为DATE，但TIME需注意达梦默认带毫秒而 MySQL 5.6+ 才支持TIME(3) - 特别注意
CLOB字段：达梦中可能存超长文本，MySQL 的TEXT最大 64KB，MEDIUMTEXT最大 16MB，LONGTEXT才支持 4GB；若源数据超过MEDIUMTEXT上限，得拆分或改用LONGTEXT - 外键约束要禁用：
SET FOREIGN_KEY_CHECKS = 0;再导入，否则因依赖顺序失败
字符集和大小写敏感配置不匹配，会导致乱码或查不到数据
达梦默认初始化时若设了 CHARSET=1（即 UTF-8），但 MySQL 实例是 utf8mb4，表面兼容，实际插入含 emoji 或四字节 UTF-8 字符时会截断或报错 Incorrect string value。
- MySQL 目标库、目标表、字段级都显式指定
CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci - 达梦端导出前确认连接参数带
charset=utf8（不是 utf-8），避免 JDBC 驱动误判 -
CASE_SENSITIVE=0（达梦关闭大小写敏感）时，其对象名全小写，但 MySQL 默认lower_case_table_names=1，表名转小写存储；若达梦源表名含大写如UserInfo，MySQL 里建表必须用反引号：CREATE TABLE `UserInfo`，否则 DTS 会找不到对应目标表
命令行模式比图形界面更可控，尤其对大批量表
图形界面在迁移超过 200 张表时容易卡死或丢任务，且无法跳过单张失败表继续执行；命令行模式可精确控制每一步。
- 用
dts命令加-f指定配置文件，关键字段如：src_db_type=DM、dst_db_type=MySQL、table_list_file=/path/to/table_list.txt -
table_list.txt每行一个表名，支持通配符如order_%，但不支持正则；想排除某些表得靠脚本预处理 - 加
-skip-error参数让 DTS 遇到单表错误（如字段类型不兼容）时跳过，继续下一张；否则整个任务中断 - 导出阶段用
dtsexport先落地为 CSV，再用 MySQL 的LOAD DATA INFILE导入，能规避 JDBC 批量插入的内存溢出问题
增量同步不可用，全量迁移后无持续追平能力
达梦 DTS 到 MySQL 是单向、一次性全量迁移，没有类似 MySQL Binlog 的日志订阅机制，也不支持 CDC 或 WAL 解析，因此无法开启增量同步。
- 业务停机窗口必须覆盖从“最后一条数据导出”到“应用切流”的全部时间，期间源库写入的数据会丢失
- 若需准实时同步，只能在外围加一层：比如用 Flink CDC 监听达梦的归档日志（需开启 ARCHIVELOG + supplemental logging），解析变更后写入 Kafka，再由消费者写入 MySQL
- DTS 自带的“校验”功能仅比对行数和抽样哈希，不校验字段级内容差异；发现不一致时无法定位哪一行哪一列错了，得靠
SELECT MD5(CONCAT(...))手动比对
真正麻烦的不是操作步骤，而是达梦和 MySQL 在类型语义、空值处理、默认值生成逻辑上的隐性差异——比如达梦的 SYSDATE 插入时是带时区的，MySQL 的 NOW() 默认不带，迁移后时间戳会偏移。这些细节不跑真实数据根本暴露不出来。
