做了这么多年数据库相关的活儿跨库迁移是绕不开的一个坎。尤其是Oracle往MySQL迁项目背景五花八门有的是集团统建系统要下沉到本地化部署有的是为了降成本从商业数据库切到开源栈还有的是数据仓库前置库要换成轻量方案。我最近正好用Navicat Premium完整做了一次Oracle到MySQL的数据迁移整个过程踩了不少坑也总结了一套相对靠谱的流程。这篇就按实际操盘的顺序把从选型、预检、表结构转换、数据灌入到事后校验的完整过程写出来给同样要干这活的朋友一个参考。整个迁移用到的核心工具就是Navicat Premium它内置的“数据传输”功能可以直接在Oracle和MySQL之间建通道不需要先导出成中间文件再导进来省了很多事。不过工具只是省力真正决定迁移质量的还是前期准备和对两个数据库差异的理解。下面逐一展开。1. 迁移方案选型与整体设计思路1.1 为什么用Navicat Premium而非手工或命令行先说结论如果是一次性的、数据量在GB级别以下、表结构不算特别变态的迁移Navicat Premium基本是最省心的选择。有人会问直接用Oracle的expdp导出dmp再用MySQL的source导入不行吗理论上行但实操很痛苦。dmp是Oracle私有二进制格式MySQL根本不认中间还得再过一层SQL解析转换。更麻烦的是Oracle和MySQL的SQL方言差异不小字段类型、函数、日期处理、保留字都不一样直接灌SQL脚本大概率在第一个CREATE TABLE就报错。命令行方案比如写Python脚本用cx_Oracle和pymysql逐表读再写灵活度高但代码量大调试成本高而且对非开发背景的DBA不友好。我自己也写过类似的脚本最后发现大部分时间都花在了类型映射和特殊字符清洗上纯属重复造轮子。Navicat Premium的“数据传输”工具把这条链路简化成了三步配好两个连接、勾选要迁移的表、点开始。它内部会做类型映射、批量提交、错误跳过这些事对绝大多数场景够用了。而且它支持在迁移前预览和修改字段映射关系等于给了你一层保险发现问题可以在启动前就调整。1.2 迁移链路的整体架构与前置条件这次迁移的目标库是MySQL 8.0InnoDB引擎utf8mb4字符集源库是Oracle 11g R2生产库数据量约300G单表最大的在1.2亿行左右。链路是Oracle实例 → Navicat Premium客户端 → MySQL实例网络走的是内网专线。这里有个关键点Navicat Premium只是一个客户端工具它不负责“搬运”数据文件而是逐条把源库的数据SELECT出来再INSERT到目标库。所以它的性能上限受两个因素制约一是客户端机器到两个数据库的网络带宽和延迟二是客户端本身的单线程处理能力。大表的迁移速度不会特别快但胜在稳定可控出错了能断点续跑其实Navicat没有真正意义的断点续跑但可以按条件分批续传后面细说。前置条件里最容易被忽略的是Oracle客户端的OCI库。Navicat Premium连接Oracle不是纯JDBC直连而是通过本机的Oracle Instant Client或者完整版Oracle Client提供的OCI接口。机器上没装OCI的话连接测试会直接报错。我第一次用Mac版Navicat连Oracle时就被这个坑过后来装了对应架构的Instant Client并配好环境变量才通。MySQL这边相对简单官方Connector/C是Navicat自带的基本不用额外配置。只要MySQL实例开了远程访问权限创建一个有建库建表权限的账号就行。2. 迁移前的预检与准备这些事没做后面全是坑2.1 源库与目标库的权限、版本、字符集核对迁移前一定要先做一轮体检别拿到库就开始导。我一般按这个顺序检查版本确认Oracle 11g和MySQL 8.0之间的类型映射是最成熟的如果是Oracle 19c或者MySQL 5.7/5.6个别映射会有差异需要提前看Navicat的映射规则。权限确认Oracle侧需要能读取数据字典视图DBA_TABLES、DBA_TAB_COLUMNS等的权限实际迁移时至少要有SELECT ANY TABLE的权限否则非当前Schema的表虽然能看到名字但查询时直接报ORA-00942。如果表是别人Schema下的还需要GRANT SELECT权限。MySQL侧需要有CREATE、ALTER、INSERT、DELETE、INDEX权限如果走数据传输里的“删除目标表”选项最好再给个DROP权限。字符集数据库迁移最怕乱码。Oracle库查一下NLS_CHARACTERSET如果是ZHS16GBK而MySQL目标库是utf8mb4中文和生僻字比如GBK里没有的emoji都有可能出问题。稳妥的做法是MySQL侧建库时直接指定utf8mb4Navicat会在迁移时做字符集转换。目标库预处理在MySQL里先手工建好目标数据库并指定字符集和排序规则。我习惯用CREATE DATABASE target_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;注意排序规则别用utf8mb4_general_ci虽然它排序快一些但对中文和特殊字符的处理不如utf8mb4_unicode_ci严谨。如果后续要做全文索引utf8mb4_unicode_ci也兼容性更好。2.2 表清单梳理与大表、无主键表标记拿到源库后建议先跑一遍元数据查询把要迁移的表清单拉出来。Navicat里的“数据传输”能自动列出所有表但手工做一张Excel清单更利于把控进度尤其是在表数量上百的时候。我的做法是查Oracle的数据字典把表名、行数估算值NUM_ROWS、是否分区、是否有主键、最大字段类型都记下来SELECT table_name, num_rows, partitioned FROM all_tables WHERE owner SOURCE_SCHEMA ORDER BY num_rows DESC;这张清单的核心作用是帮你提前识别两类风险表一是大表行数超过千万。这类表在Navicat传输时建议单独勾选不跟小表混在一起跑否则中途某个小表报错会导致整个批次失败回滚浪费时间。二是无主键或无唯一索引的表。MySQL的复制、binlog、甚至后续的增量同步都依赖主键如果源表没主键迁移过去后建议在MySQL侧补一个自增ID不然后续做数据比对、增量更新时会非常痛苦。2.3 磁盘空间与网络带宽预估这是一个经常被忽视的环节。Oracle数据文件300G不代表你MySQL目标库只需要300G。MySQL的InnoDB引擎表数据和索引存储在一起但碎片率、列格式DYNAMIC还是COMPACT、字符集转换后的字节数增长都会让实际占用比源库更大。中文从ZHS16GBK2字节转成utf8mb43字节光这一项数据体积就可能膨胀50%。另外Navicat做数据传输时客户端所在机器会充当数据中转站不需要额外的磁盘空间存储中间文件它走的是内存流但如果是用“转储SQL文件”再导入的方式那中间SQL文件的大小就非常可观了甚至可能达到源库大小的1.5到2倍。所以能用“数据传输”直连就不要先导出再导入。网络带宽上千兆内网环境下Navicat的传输速度大概能跑到50MB/s到100MB/s300G的数据按这个速度算纯数据迁移时间大约在1到1.5小时之间。但如果客户端和数据库之间跨公网或者带宽有限传输时间会成倍增加这种情况建议先做一次小表试迁移来估算速度。3. 表结构迁移与数据类型映射Oracle和MySQL的“翻译官”3.1 Navicat自动迁移的默认映射规则Navicat的数据传输工具在勾选“创建表”选项后会读取源表的DDL然后按内置规则翻译成MySQL的CREATE TABLE语句。默认映射大致如下Oracle类型MySQL类型说明VARCHAR2(n)VARCHAR(n)字符语义一致直接映射NVARCHAR2(n)VARCHAR(n)注意字符集NVARCHAR2是Unicode语义NUMBER(p, s)DECIMAL(p, s)p18时会映射成DECIMAL注意精度NUMBER(1)TINYINT(1)MySQL里TINYINT(1)经常被当布尔用业务侧要注意NUMBER(10)INT / INTEGER只要p在INT范围内就映射成INTNUMBER(19)BIGINT19位就是BIGINT上限DATEDATETIMEOracle的DATE含时分秒MySQL的DATE只有日期必须用DATETIMETIMESTAMPTIMESTAMP但默认值和时区处理逻辑不同CLOBLONGTEXT4GB上限一般够用BLOBLONGBLOB二进制大对象直接对位RAW(n)VARBINARY(n)字节流注意长度单位FLOAT(b)FLOAT / DOUBLE二进制精度可能变化LONGLONGTEXTOracle的LONG是历史遗留类型映射没问题但有兼容性风险ROWID不支持需要手工去掉ROWID没有实际业务意义3.2 默认映射的“坑”与手工修正默认映射看着挺美好但实际跑出来往往有几个地方要手工调整。第一个坑NUMBER(p, s)带s的情况。Oracle里NUMBER(10, 2)表示总长度10位、小数位2位MySQL映射成DECIMAL(10, 2)没问题。但Oracle允许NUMBER(38)也就是最大38位精度的数字MySQL的DECIMAL最高只支持65位但Navicat可能直接映射成DECIMAL(38, 0)这就把小数位丢了。如果源表里有NUMBER(38, 6)这种定义一定要在映射界面手动改成DECIMAL(38, 6)否则数据精度会丢而且不会报错——这是最危险的静默错误。第二个坑Oracle的DATE类型。这个我特别想强调Oracle的DATE实际上是一个包含时分秒的日期时间类型用法上等同于MySQL的DATETIME。Navicat默认把它映射成DATETIME这个是对的。怕就怕有人手工改成DATE迁移后所有的时间字段都变成00:00:00业务直接崩。我自己遇到过这个问题排查了半天才发现是目标表结构被手工改过。第三个坑CLOB字段的迁移方式。Oracle的CLOB在Navicat里默认映射成LONGTEXT单值大小上限4GB一般不会超出。但CLOB的读取和写入走的是LOB定位器Navicat在批量提交时如果遇到超大CLOB几百MB级别的XML或JSON可能会把整个事务撑爆。所以含CLOB的大表建议在传输选项里把“每次批处理的行数”调小一些比如从默认的1000降到100避免单批数据体积过大。3.3 索引、约束和自增序列怎么处理Navicat在创建目标表时会连带创建主键和普通索引。但有两个东西它默认不做需要你手工补一是Oracle的SEQUENCE转MySQL的AUTO_INCREMENT。Oracle表的主键通常来自序列比如SEQ_USER_ID.NEXTVAL迁移后MySQL表结构里不会有AUTO_INCREMENT属性。处理方法是在MySQL目标表上手工修改主键列为自增ALTER TABLE user_info MODIFY COLUMN id BIGINT NOT NULL AUTO_INCREMENT;然后把自增起始值设置成源表当前最大ID加1ALTER TABLE user_info AUTO_INCREMENT 1000001;如果不做这一步业务新增数据时主键就可能冲突特别是应用代码里还残留着Oracle的序列调用逻辑的话比如直接用SELECT SEQ.NEXTVAL FROM DUAL去取新ID那在MySQL里会直接报错等于逼着业务侧改代码。二是Oracle的触发器Trigger。如果你迁移的库里有大量用于维护审计字段、复杂默认值的触发器它们不会跟着数据迁移过来。Navicat的“数据传输”不迁移存储过程、函数、触发器这些PL/SQL对象它只处理表结构和表数据。这意味着迁移完以后所有依赖数据库端逻辑的字段比如自动写入CREATED_DATE、更新LAST_UPDATED_DATE等都会失效。这个必须提前告知业务方让他们在应用层补齐逻辑或者在MySQL里用新语法重建触发器。MySQL的触发器语法跟Oracle差异很大不能直接复制SQL需要重写。三是Oracle的虚拟列和物化视图。虚拟列Virtual Column在Navicat的默认映射里可能会被当成普通列迁移但它的生成表达式是Oracle语法MySQL不认识结果就是建表时报错。物化视图就更不用说了MySQL没有原生物化视图需要改成普通表定时刷新的方案。这些都属于迁移范围之外但迁移后必须处理的存量问题最好在项目计划里单独列出来。4. 核心实操Navicat Premium数据迁移全流程4.1 第一步配置Oracle与MySQL连接在Navicat里“连接”面板分别创建Oracle连接和MySQL连接。Oracle连接的关键配置项有主机Oracle所在服务器IP端口默认1521服务名或SID这里最容易弄混。Oracle 11g默认用SID但很多云数据库对外暴露的是Service Name服务名。填错了会报ORA-12514或ORA-12505。建议直接问DBA要tnsnames.ora里的NET_SERVICE_NAME。连接测试如果提示找不到OCI库类似“Cannot load OCI DLL”就要去Oracle官网下载对应版本的Instant Client解压后把路径填到Navicat的“OCI library”配置项里。MySQL连接的配置相对简单主机、端口默认3306、用户名、密码填入即可。连接测试通过后建议右键连接打开“编辑连接”在“高级”标签里确认“使用MySqldump工具”和“使用mysql工具”的路径是否正确。这两个路径用于后续的备份还原虽然数据传输模式下用不到但提前配好没坏处。4.2 第二步使用“数据传输”工具进行表结构数据全量迁移具体操作路径是在Navicat主界面选中源Oracle连接下的某个Schema或者直接右键数据库名点菜单栏的“工具”→“数据传输”。在弹出的窗口里需要做以下设置源选择要迁移的Oracle数据库Schema不要选整个实例否则会把系统表、系统视图也带进来。目标选择之前建好的MySQL数据库。传输选项“创建表” 勾选这样会自动建目标表“数据” 勾选这是数据迁移的主开关“删除目标表”如果目标表存在且要覆盖就勾选如果目标库是空的可以不勾“使用事务”建议勾选这样单个表的数据要么全部写入要么全部回滚不会出现半截数据“每次批处理行数”默认1000按需调整对象列表这里会把源库里的所有表列出来可以在这一步筛选需要迁移的表也可以单独调整每个表的目标映射。点击“开始”后Navicat会进入传输进度界面能看到每个表的状态、传输行数、耗时、错误信息。整个过程建议人盯着至少在头几分钟内确认没有报错再离开。4.3 第三步分批迁移大表与续传技巧一次性把所有表都勾上跑如果中途有一张表出错Navicat默认会继续跑后面的表但出错的那张表不会自动重试。我之前遇到的情况是某张表的CLOB字段里有非法字符直接中断了整张表后面的表还是正常跑完了但那张表始终是0行很隐蔽。所以稳妥的做法是分两批第一批迁移所有小表、配置表数据量小执行时间短适合整体跑一遍发现明显的类型映射问题。第二批逐个迁移大表。中途如果一张表跑到一半报错可以用“筛选条件”功能做续传。Navicat的数据传输里有一个“高级”选项可以给源表加WHERE条件。比如一张1.2亿行的表可以先传主键ID 0到3000万的部分WHERE id 0 AND id 30000000跑完后再把条件改成下一段这样即使中间失败了顶多重跑当前段不用从头再来。这个技巧在数据量巨大、网络不稳定的场景下能救命。4.4 第四步使用“Run SQL File”迁移视图和存储过程Navicat的数据传输不迁移视图View、存储过程Procedure、函数Function、触发器Trigger等对象。这部分的迁移方式通常是在Oracle连接里右键数据库 → “转储SQL文件” → “仅结构”然后把SQL文件用文本编辑器打开删除Oracle特有语法改成MySQL语法前缀。改动点包括把CREATE OR REPLACE FORCE VIEW改成CREATE OR REPLACE VIEW把存储过程里的IS改成ASMySQL用AS但其实两种都兼容关键是参数和变量声明方式把SELECT ... FROM DUAL去掉MySQL不需要DUAL表虽然8.0版也支持了但正规写法不写把字符串拼接符||改成CONCAT()把SYSDATE改成NOW()把TO_CHAR(字段, YYYY-MM-DD)改成DATE_FORMAT(字段, %Y-%m-%d)把NVL(字段, 0)改成IFNULL(字段, 0)把DECODE(a, b, c, d)改成CASE WHEN a b THEN c ELSE d END改完之后在MySQL连接上右键目标数据库选择“运行SQL文件”把改好的SQL文件跑一遍就能把视图和存储过程建出来。这个过程不能省否则迁移后应用系统一启动就报“找不到视图”或“Procedure不存在”的错误。注意存储过程这类代码逻辑的转换最好找开发同事一起过一遍因为不只是语法差异Oracle的PL/SQL和MySQL的存储过程在异常处理、游标、事务控制上都有差异只做语法翻译容易遗漏业务逻辑。4.5 第五步验证数据完整性与统计信息更新数据迁移完成不等于迁移结束。我习惯做三层校验第一层是行数比对。在Oracle查每个表的COUNT(*)在MySQL再查一遍两张表列出来比对。但这种全表COUNT在大表上很慢可以用MySQL的information_schema.tables里的TABLE_ROWS和Oracle的NUM_ROWS先粗比然后对大表抽样精确COUNT。第二层是抽样内容比对。取每条关键业务表的前100条和最后100条手工比对几个非索引字段确认数据内容和顺序没有错位。第三层是运行MySQL的ANALYZE TABLE让优化器重新统计表信息ANALYZE TABLE user_info;Oracle端迁移过来的表在MySQL里统计信息是空的如果直接跑SQL执行计划可能完全走偏该走索引的走了全表扫描。ANALYZE之后执行计划就正常了。5. 常见问题与排查技巧实录以下这些坑都是我实际迁移中踩过的列出来供参考。5.1 连接Oracle时提示“Cannot load OCI DLL”这是Navicat连Oracle最常见的问题。原因就是本机缺少Oracle Client的OCI库或者Navicat没有找到它。解决方式去Oracle官网下载“Instant Client”对应版本注意选和Navicat位数一致的64位Navicat要64位Instant Client32位同理。解压到本地比如C:\oracle\instantclient_21_12。在Navicat的Oracle连接配置里下方有一个“OCI library”的输入框直接浏览选择刚才解压目录下的oci.dll。如果是在Mac上路径类似选libclntsh.dylib。设置完成后重新测试连接即可。5.2 迁移时字段类型报错Unknown column type这个报错通常出现在Oracle 12c以后的一些新类型上比如SYS.XMLTYPE、SDO_GEOMETRY、INTERVAL DAY TO SECOND等。Navicat对新类型的映射不完善遇到不认识的就直接报错。解决办法在“数据传输”的映射界面手动把这些列的类型改成MySQL支持的等价类型比如XMLTYPE改成LONGTEXTSDO_GEOMETRY改成JSON或GEOMETRY取决于业务是否要用空间计算。如果源表里这类列数据量大建议先只迁移结构再单独写脚本处理数据。5.3 Oracle的CLOB数据导到MySQL后变截断大字段截断的问题通常不是Navicat的限制而是MySQL侧的max_allowed_packet参数设置太小。MySQL默认值是64M或更小如果单条INSERT语句里包含了一个超过这个值的CLOB字段内容导入就会失败。解决方式SET GLOBAL max_allowed_packet 1073741824; -- 1GB注意这个参数是动态的修改后当前会话立即生效但重启MySQL后会失效。需要在my.cnf的[mysqld]段里也加上对应配置才能持久化生效。另外在Navicat传输大字段表时建议开启“使用事务”并在“高级”选项里把“每次批处理的行数”降低避免单条INSERT体积过大。5.4 主键为空的表迁移后出现重复数据这个坑不常见但一旦遇到就很隐蔽。Oracle表本身没有主键但业务上可能有重复数据。Navicat创建目标表时如果也照搬了无主键结构那么数据灌入后可能有大量重复行后续按某字段去重时就会出问题。我的建议是无主键表迁移完成后主动加一个业务无关的自增主键ALTER TABLE your_table ADD COLUMN id BIGINT PRIMARY KEY AUTO_INCREMENT FIRST;有了这个自增主键后续做数据修复、增量同步、甚至简单的分页查询都更安全。如果担心业务逻辑对列顺序有依赖可以用AFTER关键字把自增列加到末尾不改变原有列顺序。5.5 迁移后MySQL写入慢或大批量更新卡死数据迁过去之后如果业务跑起来明显变慢先别急着说MySQL不如Oracle。检查三件事是否执行了ANALYZE TABLE没有统计信息的表会生成极差的执行计划。目标表是否没加索引Oracle里的索引虽然迁过去了但如果有复合索引、函数索引、位图索引MySQL并不都支持尤其是位图索引MySQL 8.0之前完全没有这类索引迁移时会直接丢失需要业务侧重新设计。大表是否没有分区。在Oracle里做了范围分区的表到MySQL里如果直接退化成单表查询性能会显著下降。MySQL 8.0支持RANGE、LIST、HASH、KEY分区可以按原表的分区键重新设计分区方案但要注意分区键必须是主键的一部分这个限制和Oracle不同设计时要特别注意。6. 迁移完成后的常见补充操作数据导完、验证通过这一步是很多人会掉的坑以为迁移完了就直接给业务方交接结果业务一上线就各种报错。补充操作主要有以下几个。补充操作一是更新MySQL的AUTO_INCREMENT。如果你在迁移前修改了表结构加了自增主键或者源表用了Oracle的序列那么一定要把MySQL的AUTO_INCREMENT设置成源表最大ID1否则新插入的数据会主键冲突。这个前面提到了再强调一次因为实际工作中这个隐患不报错直到业务写入才爆。补充操作二是核对MySQL的字符集排序规则。Oracle数据库里的中文排序规则和MySQL的utf8mb4_unicode_ci排序结果不完全一样如果业务依赖ORDER BY中文排序迁移后可能看起来怪怪的。建议在测试阶段专门跑一遍中文排序的SQL确认排序结果是否可接受。补充操作三是检查时区设置。Oracle的SYSTIMESTAMP和MySQL的CURRENT_TIMESTAMP对时区的处理逻辑不同。MySQL的time_zone默认是SYSTEM如果目标服务器时区和业务时区不一致NOW()返回的时间可能对不上。建议在连接参数或MySQL配置文件里明确设置时区比如SET GLOBAL time_zone 08:00;转移过程中如果涉及TIMESTAMP WITH TIME ZONE类型的字段尤其要关注这一点。补充操作四是索引碎片整理。大批量INSERT进来的数据InnoDB的B树索引很容易产生碎片跑一段时间后写入性能会下降。建议在迁移完成后跑一次OPTIMIZE TABLE等价于重建表来整理碎片。注意这个操作会锁表要在业务低峰期做。7. 迁移性能优化让数据传输跑得更快Navicat的默认传输参数偏保守实际使用时可以针对大表做几项调整明显提升迁移速度。一是调整批处理行数。默认的1000行每批对OLTP小表没问题但对大表来说太小了INSERT的执行频率太高网络往返次数也多。我实测中把批处理行数调到5000传输速度能提升30%到50%。如果目标表字段多、单行体积大批处理行数调大后单条INSERT的体积也会增大要确保max_allowed_packet足够。二是关闭“每次传输前删除目标表数据”的选项。如果你已经确定目标表是干净的没必要在传输前再删一次。这个选项开着Navicat会先执行DELETE FROM或者DROP TABLE再重建多一步操作大表上特别浪费时间。三是调整MySQL的写入相关参数。比如innodb_flush_log_at_trx_commit 2或0sync_binlog 0能显著降低磁盘写入频率加快大批量导入。但注意这些是牺牲可靠性换速度的临时参数迁移结束后一定要改回来。我个人建议如果迁移窗口允许直接用默认参数慢慢导毕竟数据一致性比速度快更重要。四是用多线程方案。Navicat的“数据传输”默认是单线程也就是同一时刻只处理一张表。如果你的源库表很多且都是小表单线程的效率确实不高。Navicat Premium 17版本部分场景支持并行传输但实测下来不是所有版本都开放。实在需要并行时可以多开几个Navicat窗口分别迁移不同批次的表物理并行。这么做的前提是目标MySQL的写入性能和磁盘IO扛得住并发否则反而会拖慢整体速度。8. 迁移质量核验清单最后提供一份自用迁移质量核验清单每次迁移完都照着过一遍核验项具体操作通过标准表数量一致性源库和目标库查询表数量完全一致行数一致性关键表逐表COUNT(*)比对大表抽样小表全量字段类型正确性抽查目标表所有字段类型与精度Number→Decimal位数为8位以上的需单独核对大字段数据完整性对CLOB/TEXT字段抽样比对长度和首尾字符无截断长度一致字符集与乱码抽查中文字段值和emoji字符显示正常无乱码主键自增起始值查询AUTO_INCREMENT值大于源表最大ID索引与约束比对源库和目标库索引数量关键业务索引不缺失存储过程与视图运行编译检查无语法错误时间字段抽样比对yyyy-MM-dd HH:mm:ss格式时分秒不丢失统计信息执行ANALYZE TABLE完成业务联调让业务方跑一轮核心冒烟用例通过这套清单看起来繁琐但实际执行下来也就半天时间。相比迁移后线上出问题再排查这点时间花得非常值。我自己做了这么多次迁移最大的体感是Navicat这个工具解决的是“把数据搬过去”的问题但真正决定迁移成败的是“搬之前怎么想”和“搬完之后做什么”。数据类型映射、自增主键、统计信息、字符集这些细节任何一个没处理到位都可能让后续的业务运行埋下隐患。希望这篇内容能帮到正打算动Oracle到MySQL迁移的朋友少走几步弯路。