去年底接手一个活儿把一个跑了三年多的MySQL业务库迁到达梦数据库上业务方给的时间很紧还反复强调“数据不能丢”。说实话一开始我是有点虚的——MySQL和达梦虽然SQL语法大体接近但细节处全是坑字段类型、保留字、大小写策略稍有偏差迁移完业务就起不来。真跑完一轮才发现用达梦自带的迁移工具小规模业务库从配置完成到数据落地三分钟内迁移完主体数据是完全可以实现的最花时间的反而在后面核对数据、调整细节上。如果你也正在规划MySQL到达梦数据库的迁移这篇文章会把我的完整思路、实操步骤、参数选择和踩过的坑一次性交代清楚。内容适用于中小规模业务库也适合被“快速迁移”要求逼着的朋友参考。1. 三分钟完成迁移的底气藏在“工具选型”和“前置准备”里1.1 为什么我坚持用自带迁移工具而不是手工建表导数据最早接到需求时团队里有人提过一套“稳妥”方案先用mysqldump导出结构手工改成达梦语法再导数据。这方案我以前也干过一张两张表还好到了几十张表、带视图带存储过程的时候完全是在挑战耐心。MySQL和达梦在数据类型、约束写法、默认值表达式上都有差异手工改结构等于把数据库的活揽到自己身上改到后半夜容易出低级错误。达梦自带的图形化数据迁移工具原理其实很简单它同时连接源端MySQL和目标端达梦读取源端元数据后自动生成目标端的建表语句和INSERT语句。也就是说结构转换、类型映射、批量插入这些事全部由工具代劳你要做的只是把两端连接信息填对、选好迁移对象、点执行。对比一下方案结构转换工作量类型映射准确度大字段/特殊类型支持适合场景手工导出再改写大容易漏依赖人工经验常常要单独处理单表或极少量表的临时迁移自己写脚本同步很大还需调试中需逐个扩展长期增量同步初次迁移反而费劲达梦自带迁移工具小工具自动转换高内置映射规则一次性全量迁移尤其适合初次接触达梦的场景我的结论很直接初次迁移、数据库结构复杂一点、又有快速交付要求的直接用自带工具。它解决的不仅是“能不能迁移成功”的问题更重要的是“迁移完能不能直接用”的问题——工具会根据达梦的语法规则重新生成对象定义不用你逐条排查语法差异。1.2 迁移前的信息收集清单比迁移本身更影响成败所谓“三分钟完成迁移”有一个被很多人忽略的前提迁移前的准备和检查必须提前做完。就像开车上路前要检查油量、胎压和导航路线数据库迁移如果连源端版本、网络连通性都没确认工具再快也白搭。我自己习惯在动手前先做一张信息清单照着填类别需要确认的内容说明源端MySQL版本号5.7还是8.0驱动选择有差异源端MySQL数据库名、用户名、密码需要具备读取元数据的权限源端MySQL库表数量、总数据量判断三分钟是否可行数据量过大时传输时间会变长源端MySQL是否包含视图、存储过程、函数、触发器这些对象在迁移时容易报错需要提前了解目标端达梦版本号、实例名、端口达梦默认端口是5236目标端达梦目标模式名、用户名、密码模式相当于MySQL中的database网络环境源端到目标端网络是否通如果跨网段需要提前测试连通性和传输速度字符集情况MySQL侧utf8mb4、达梦侧的字符集设置中文场景下这是最大的坑后面专门说还有一个容易忽略的点达梦的初始化参数。不同参数组合下同样的表结构迁移过去表现可能完全不同。比较关键的是LENGTH_IN_CHAR和CASE_SENSITIVE这两个参数一个影响字符长度计算方式一个影响标识符大小写规则。如果你有数据库初始化权限并且主要业务是中文数据建议把LENGTH_IN_CHAR设为1按字符存储如果业务SQL里大量使用小写表名CASE_SENSITIVE为0会省掉很多麻烦。这块如果没有提前确认迁移后哪怕数据进来了应用层SQL也可能报“表或视图不存在”。2. 核心配置解析驱动、连接串与类型映射里容易被忽视的细节2.1 MySQL JDBC驱动和URL写法的坑达梦的迁移工具本质上是JDBC客户端所以要连上MySQL必须先把MySQL的JDBC驱动放到工具能识别的位置。不同版本的达梦对驱动目录要求不一样常规做法是把驱动jar包复制到达梦安装目录下的驱动目录中然后重启迁移工具。我这里踩过一个坑工具明明显示驱动加载了点测试连接却直接报ClassNotFoundException。查到最后是jar包版本和MySQL Server版本不匹配。MySQL 5.7建议用5.1.x的驱动MySQL 8.0建议用8.0.x的驱动。另外一个常见问题是URL里漏参数导致连接报错或SSL握手失败。标准的MySQL连接串如下jdbc:mysql://192.168.1.100:3306/business_db?useSSLfalseserverTimezoneAsia/ShanghaiallowPublicKeyRetrievaltruecharacterEncodingutf8这几个参数各有各的用处useSSLfalse避免本机没有证书时报SSL相关错误serverTimezone指定时区不写的话驱动可能把本地时区当成UTC导致时间字段迁移后差8小时allowPublicKeyRetrievaltrue是MySQL 8.0用caching_sha2_password认证时特别容易出现的需求characterEncodingutf8则是为了保证中文写入不乱码。2.2 达梦目标端的连接配置要点目标端达梦的连接信息相对简单工具里一般需要填主机IP、端口、用户名、密码、数据库名或模式名。默认端口是5236这个要记牢因为从MySQL习惯转过来的同学经常条件反射填3306。达梦的JDBC URL格式大致是jdbc:dm://192.168.1.101:5236连接达梦的驱动类名是dm.jdbc.driver.DmDriver工具一般会内置不用额外折腾。但在工具里选择目标库时要注意它让你填的到底是“数据库”还是“模式”。达梦和MySQL的概念不是一一对应的MySQL里一个“数据库”下有表、视图等一系列对象达梦里则是“实例”下有多个“模式”每个模式下面挂表、视图等对象。迁移时通常将MySQL的database对应到达梦的一个schema也就是模式。如果填错层级建表可能建到系统模式下那是很糟糕的。2.3 字段类型映射规则工具自动完成但你要心里有数虽然迁移工具会自动生成映射但我建议动手前把常见类型的映射关系过一遍原因很简单工具默认映射通常偏保守如果你了解规则就可以在迁移前判断哪些字段需要事后调整。MySQL和达梦常见类型的大致映射关系如下MySQL类型达梦类型备注INT/INTEGERINT宽度如int(11)会被忽略BIGINTBIGINT长整型直接对应TINYINTTINYINTMySQL中用于布尔表达迁移后注意应用读取方式VARCHAR(n)VARCHAR(n)受LENGTH_IN_CHAR参数影响按字节或字符CHAR(n)CHAR(n)同上TEXTTEXT也有工具映射为CLOB实际差别不大LONGTEXTCLOB大文本类型BLOBBLOB二进制类型DATETIMETIMESTAMP时间类型对应TIMESTAMPTIMESTAMP注意默认值处理差异DATEDATE常用日期类型DECIMAL(p,s)DECIMAL(p,s)精度位数直接保留ENUMVARCHAR枚举类型会转为字符串SETVARCHAR集合类型也会转为字符串有几个容易被忽略的细节第一MySQL里用TINYINT(1)表示布尔值的习惯很常见迁移到达梦后它仍然是TINYINT。应用层如果按“0/1”读取没问题但如果代码里用true/false做映射不同驱动行为可能不同需要在迁移后做一轮联调。第二MySQL的VARCHAR字段如果用了utf8mb4字符集一个汉字占3到4个字节。达梦里如果初始化时LENGTH_IN_CHAR0VARCHAR(255)代表255个字节那中文数据实际只能存85个字符左右比MySQL里能存的少很多。这个不是数据丢失而是容量收缩会造成后期插入报“字符串超长”。所以遇到中文场景一定要核对目标库的LENGTH_IN_CHAR参数。第三MySQL的自增列AUTO_INCREMENT工具会自动转换到达梦的IDENTITY自增列。但要注意如果源表自增列已经是业务数据的一部分迁移后需要同步重置自增起点否则新插入数据可能主键冲突。3. 三分钟实操全流程从新建工程到数据落地3.1 新建迁移工程并配置数据源打开达梦自带的图形化迁移工具后第一件事是新建工程。这里没有什么高深操作给工程起个能一眼认出的名字比如mysql2dm_business_20250115然后进入数据源配置。配置源端MySQL数据源时要填这些信息驱动选择MySQL JDBC Driver主机名/IP源库地址端口默认3306数据库名要迁移的库用户名/密码有读写和读取元数据权限的账号填完后建议先点“测试连接”等工具反馈成功再继续。很多时候三分钟迁移的“三分钟”不包括你在这里排查网络和账号问题的时间。再配置目标端达梦数据源驱动选择DM JDBC Driver主机名/IP目标达梦地址端口5236用户名/密码目标模式所属用户模式名迁移到这个模式下目标端同样先测试连接。我在现场见过有人嫌测试连接麻烦结果执行到一半发现用户名密码错了——工具报错倒是很详细但这时候已经建了一部分表反而要清理重来。测试连接这一下真的省不了。3.2 选择迁移对象并调整转换选项数据源配置好后工具会列出源端MySQL里可以迁移的对象表、视图、存储过程、函数、触发器都有。我的习惯是“分主次勾选”第一轮只勾业务表跑通流程第二轮再补视图和存储过程。原因很简单视图依赖表结构如果表和视图一起迁移工具往往是按对象类型分批处理顺序不好控制。表先迁完视图的依赖就存在了报错率会低很多。对象选择完成后建议进入迁移选项页面把几个关键参数调一调。这个页面很多人不看实际上迁移效率高不高全看这里。需要注意的参数有参数项推荐值说明批量提交行数500到1000每攒够这么多行做一次批量插入太大容易占用内存太小效率低数据提取数组大小100到500从MySQL端批量读取的行数迁移失败是否继续是单条失败不中断整体任务事后统一排查是否迁移记录否不迁移自增序列的当前值迁移后手动处理并发线程数2到4小库默认即可太大反而可能影响源库我见过有人把批量提交行数调到5000想着一次多插点跑得快结果目标库内存和UNDO压力暴涨迁移中途报错。这里要理解批量提交的原理工具在内存里攒一批数据拼成批量INSERT再发给达梦。批大小越大单条事务处理的行数越多对目标库的UNDO表空间和内存消耗也越大。500到1000这个范围是很多生产迁移案例里验证过的折中值。3.3 执行迁移与进度监控配置完成后点“执行”工具会进入进度页。这时候你会在页面上看到每个对象的状态是“等待中”“正在迁移”“已完成”还是“失败”。以我迁的那个库为例库里有20多张表总计不到500万行在普通千兆网络下表结构和数据完全迁完基本在1到2分钟级别。如果都是几千行的配置类表秒级结束很正常。执行过程中有几个信号要注意一是日志级别建议调成“详细”不要用“简单”。简单日志只告诉你成功或失败而详细日志会记录具体到哪张表哪条SQL出错。排查问题的时候详细日志能省一半时间。二是执行时如果发现源端MySQL负载异常升高不用太慌。工具批量读取数据源端短时间内会有一些IO波动正常现象。但如果并发线程数开得过大比如超过8MySQL的CPU可能被打满这时候要手动暂停调低并发再继续。三是一定要留意目标端达梦的告警日志。如果工具界面显示迁移成功但达梦服务端日志里出现空间不足或回滚段过大之类的警告还是要去处理的否则后续业务运行可能出问题。3.4 迁移完成后的快速验证工具显示全部成功不代表可以收工了。我给自己定了一条规矩迁移结束后的10分钟才是真正检验迁移质量的时间。快速验证分三件事先做掉。第一件事查对象数量。登录达梦查一下表、视图、函数这些对象的数量是否跟MySQL源端一致。达梦兼容了部分Oracle风格的字典视图可以用类似下面的语句看某个模式下的表数量和MySQL里的information_schema.tables对比。-- 达梦侧查看某个模式下的表数量 SELECT COUNT(*) FROM ALL_TABLES WHERE OWNER 目标模式名;第二件事查数据行数。随便挑三到五张有代表性的表用COUNT(*)对比两边行数。达梦里可以直接执行SELECT COUNT(*) FROM 模式名.表名;第三件事抽查关键数据。只对比行数还不够行数一样不代表内容一样。我会挑一张带时间字段、一张带金额字段、一张带大文本字段的表分别查一下MAX(时间字段)、SUM(金额字段)、MAX(文本长度)跟源端比对。这种方法比全表比对快又能抓住绝大多数转换问题。4. 实测中的高频踩坑与排查思路4.1 驱动加载失败ClassNotFoundException这类报错这是新手最容易遇到的第一关。现象是测试连接没有反应或日志里直接报找不到驱动类。排查思路按顺序来确认MySQL驱动jar包已复制到达梦迁移工具的驱动目录中然后重启迁移工具。有些版本的工具只在启动时加载一次驱动的路径缓存不重启就会一直提示找不到。确认jar包版本与MySQL服务端版本匹配MySQL 5.7配5.1.x驱动MySQL 8.0配8.0.x驱动交叉使用很容易出幺蛾子。确认工具所在机器有可用的JDK环境。迁移工具是用Java写的如果系统的Java路径不对驱动加载也会异常。这个问题的本质是“工具没找到驱动”不是“工具连不上MySQL”所以不要在连接串和防火墙上死磕先回驱动加载这一步排查。4.2 保留字冲突与对象名大小写问题MySQL里有一批保留字比如order、group、describe、system等很多老表直接拿来做字段名或表名平时在MySQL里加反引号也能正常跑。迁到达梦后工具会自动给这些名字加双引号建表本身能成功但问题出在后续应用层SQL上——如果你写的SQL没带双引号达梦会把名字统一转成大写再解析结果就是“标识符无效”或“表或视图不存在”。另一个高发问题叫大小写敏感。达梦初始化参数CASE_SENSITIVE为1时标识符是大小写敏感的而且默认会把不带引号的SQL语句里的名字转成大写。MySQL一般建表用的都是小写表名迁移到达梦后如果不加引号查询小写表名就会一直报“表或视图不存在”。实践经验是这样的手动执行验证SQL时要么让表名带双引号且大小写与源端一致要么立刻用ALTER TABLE ... RENAME TO把表名改成大写统一管理。如果应用层SQL都是动态拼的小写表名项目允许的话初始化的达梦实例直接把CASE_SENSITIVE设为0会规避这一类问题。但改初始化参数必须在实例创建时决定已经初始化完的库改不了只能重建实例或挨个改表名。字段名如果是保留字我建议在迁移前就在源端改掉比如order改成order_nogroup改成group_name。别等迁到一半再回过头来处理后面业务联调会一直踩这个坑。4.3 中文写入报字符串超长和乱码问题中文导致的问题我把它分两个场景超长和乱码。超长的问题在前面提过根因是达梦的VARCHAR(n)如果实例LENGTH_IN_CHAR0n是按字节算的。MySQL里一个utf8mb4的VARCHAR(100)在中文字符下最多存100个汉字到达梦按字节算就只能存33个汉字左右。迁移工具虽然迁移成功了但后续业务插入新数据时会频繁报“字符串超出长度限制”。排查和解决办法有三个方向查一下目标达梦实例的参数SELECT * FROM V$DM_INI WHERE PARA_NAMELENGTH_IN_CHAR;如果是0需要评估现有字段长度是否够用。如果把所有VARCHAR字段长度统一放大可以用SQL批量生成ALTER TABLE语句比如把VARCHAR(50)改成VARCHAR(200)但这样会影响后续的存储规划不推荐无脑放。最佳方案是初始化实例时就设置LENGTH_IN_CHAR1让VARCHAR(n)按字符计算。如果在已初始化的实例上迁移那只能针对中文数据较长的字段做手工调整。乱码的问题则通常出在源端连接串没有指定characterEncodingutf8或者迁移工具里没有指定字符集。工具读取时已经乱码迁过去自然也是乱码。判断是否是读取乱码的方法很简单导出前先看工具界面上的数据预览如果页面上的中文已经是乱码就别执行迁移了先回头改连接串。4.4 迁移结果有差异的核对方法有时候工具显示成功、表数量一致、行数也一致但业务一跑就出问题。典型的场景是某张表的日期字段都是NULL某张表的金额精度变了或者自增列起点不对导致主键冲突。这种问题不能靠等业务反馈来发现要在迁移验证阶段就主动查。我在3.4节提到的抽查法用于常规校验如果时间更充裕可以做到更完整的校验。先说一个性价比很高的校验技巧选几张核心表用MD5聚合做快速比对。MySQL和达梦不一定有完全一样的聚合函数写法但这个思路可行在MySQL侧把某张表所有行的关键字段拼接起来计算聚合哈希。先按主键排序用MD5(CONCAT_WS(|,字段1,字段2,...))再加总。达梦侧可以用兼容的写法计算同样逻辑的哈希。对比两侧聚合结果是否一致。这种校验比COUNT(*)可靠得多能发现字段值在迁移过程中被截断或替换的问题。我还在一次迁移里遇到过建表成功但部分外键约束没迁移过来的情况工具默认不会报这一点但应用层如果依赖数据库外键兜底后续就会出问题。所以迁移后建议查一下目标端外键约束数量跟源端对比。5. 最后再分享一点个人体会坦率说“三分钟完成迁移”这个说法多少有点标题党的意思。真实情况是工具的传输过程确实快但前提是你把驱动、连接串、目标参数、对象范围这些东西都提前弄明白。我自己的例行做法是先迁一张小表验证配置再迁核心表最后全量跑。第一次迁表成功控制在三分钟内没有问题但如果你连源库都连不上那三分钟连排查报错都不够用。学到的一个教训是迁移工具只是帮你把砖搬过去搬完之后房子能不能住还得靠你把墙壁、水电、门窗都检查一遍。每次迁移完我习惯把三样东西专门过一遍字段长度和字符集、自增列起点、保留字字段名。这三个点覆盖了八成以上的迁移后遗症。后续如果遇到达梦和MySQL在SQL语法上的小差异也不用慌大部分都能靠调整SQL兼容过来关键是你得知道差异在哪儿而不是等业务半夜报警。