大家好，我是数据库小学妹 👋
前段时间，一家制造企业找到我们，要把跑了七年的Oracle系统迁到国产数据库。我接了评估报告一看，心里没底。数据类型对不上，存储过程全要改，数据还不能丢。这是硬仗。
今天我把这次迁移踩过的坑、趟出来的路，原原本本写下来。朋友，如果你也在做异构数据库迁移，这篇或许能帮你少走弯路。
为什么说异构迁移最难的不是数据，而是"习惯"？
很多人觉得迁移就是导数据。其实数据导出导入反而是最简单的。真正难的是应用层的适配。
Oracle用了一千多个存储过程，两百多个触发器，几十个定时任务。这些代码里藏着大量Oracle特有的语法。换库不改代码，直接报错。
我做迁移的第一步，不是导数据，而是做应用兼容性评估。把每一段PL/SQL拆开看，逐行标记不兼容的地方。
| 评估维度 | Oracle特性 | 迁移难度 | 备注 |
|---|---|---|---|
| 存储过程 | PACKAGE/PROCEDURE/FUNCTION | ★★★★ | 语法差异大，逐行改写 |
| 同义词/DBLINK | SYNONYM/DBLINK | ★★★ | 目标库可能不支持 |
| 数据类型 | NUMBER/CLOB/NCLOB/BLOB | ★★☆ | 需目标库逐一对应 |
| 序列/自增 | SEQUENCE | ★★☆ | 可替换为AUTO_INCREMENT |
| 异常处理 | EXCEPTION WHEN | ★★☆ | 语法不同，逻辑可迁移 |
| 触发器 | TRIGGER | ★★☆ | 语法差异，逻辑迁移 |
评估完我才知道，这次迁移的工作量比预期大了三倍。
数据类型映射：从NUMBER到VARCHAR2，逐一对照
Oracle和MySQL（以及兼容MySQL的国产数据库）在数据类型上的差异，比我想象的大。
NUMBER类型。Oracle的NUMBER可以表示整数、小数、浮点数，一个类型通吃。到了MySQL，要拆开看。整数用BIGINT或INT。带小数的用DECIMAL(M,D)。我一开始图省事，把NUMBER全转成DECIMAL(20,6)。上线后发现索引效率掉了不少。原因很简单：DECIMAL是字符串存储，索引查找比整数慢。该用BIGINT的地方，必须用BIGINT。
正确的映射方式是这样的：
-- Oracle 源端CREATETABLEorders(order_id NUMBER(19),-- 订单号amount NUMBER(12,2),-- 金额quantity NUMBER(10),-- 数量statusNUMBER(2)-- 状态码);-- MySQL/国产数据库 目标端CREATETABLEorders(order_idBIGINT,-- 订单号，19位整数amountDECIMAL(12,2),-- 金额，保留2位小数quantityINT,-- 数量，10位整数足够statusTINYINT-- 状态码，2位用TINYINT);VARCHAR2的坑。Oracle的VARCHAR2默认按字节计算长度。VARCHAR2(10)能存10个英文字母，但存中文可能只能存3个。转到UTF-8编码的目标库，要按字符重新计算。我的做法是：先查源端最大实际长度，再乘以3（UTF-8最大字节数），最后向上取整到标准值。
DATE和TIMESTAMP。Oracle的DATE包含时分秒，相当于MySQL的DATETIME。这个好办。但Oracle的TIMESTAMP(6)带6位微秒精度，目标库如果只支持秒级精度，毫秒数据就丢了。我搞错过一次。把一个TIMESTAMP(6)的字段直接转成了DATETIME，上线后客户反馈时间戳对不上。排查半天才发现，是微秒截断导致的。
CLOB和TEXT。Oracle的CLOB能存4GB文本。MySQL的TEXT也够大。但CLOB的读写方式不同。Oracle用DBMS_LOB包操作，MySQL直接当字符串处理。这意味着所有读写CLOB的代码都要改。
-- Oracle 读写CLOBDECLAREv_clob CLOB;BEGINSELECTcontentINTOv_clobFROMarticlesWHEREid=1;DBMS_LOB.APPEND(v_clob,'追加内容');UPDATEarticlesSETcontent=v_clobWHEREid=1;END;-- 迁移后（MySQL/国产数据库）UPDATEarticlesSETcontent=CONCAT(content,'追加内容')WHEREid=1;存储过程改写：PL/SQL到标准SQL的翻译过程
这是迁移工作量最大的部分。我把改写的规则整理成了一张表：
| Oracle语法 | 改写方式 | 难度 |
|---|---|---|
| PACKAGE | 拆分存储过程+函数，去掉包体 | ★★★ |
| CONNECT BY递归 | 替换为WITH RECURSIVE | ★★★ |
| EXCEPTION WHEN | 改用DECLARE … HANDLER | ★★☆ |
| SYS_REFCURSOR | 改为游标或直接查询返回 | ★★☆ |
| DUAL表 | 去掉FROM DUAL | ★☆☆ |
| DECODE() | 替换为CASE WHEN | ★☆☆ |
| NVL() | 替换为IFNULL()或COALESCE() | ★☆☆ |
| SYSDATE | 替换为NOW() | ★☆☆ |
| ROWNUM | 替换为LIMIT | ★☆☆ |
实际改写时，最难的是带PACKAGE的复杂存储过程。一个包体里有几十个过程和函数，互相调用，层层嵌套。我的做法是：先理清调用关系，画出依赖图，然后逐个拆解。把PACKAGE拆成独立的存储过程，去掉包级别的变量，改为参数传递。
来看一个实际例子：
-- Oracle 原始包定义CREATEORREPLACEPACKAGE pkg_orderASPROCEDUREcreate_order(p_customer_idINNUMBER,p_product_idINNUMBER,p_quantityINNUMBER,p_order_idOUTNUMBER);FUNCTIONget_order_status(p_order_idINNUMBER)RETURNVARCHAR2;ENDpkg_order;-- Oracle 包体CREATEORREPLACEPACKAGE BODY pkg_orderASg_seq_counter NUMBER :=0;-- 包级变量PROCEDUREcreate_order(p_customer_idINNUMBER,p_product_idINNUMBER,p_quantityINNUMBER,p_order_idOUTNUMBER)ISv_stock NUMBER;BEGIN-- 检查库存SELECTstockINTOv_stockFROMinventoryWHEREproduct_id=p_product_id;IFv_stock<p_quantityTHENRAISE_APPLICATION_ERROR(-20001,'库存不足');ENDIF;-- 生成订单g_seq_counter :=g_seq_counter+1;p_order_id :=TO_NUMBER(TO_CHAR(SYSDATE,'YYYYMMDD')||LPAD(g_seq_counter,6,'0'));INSERTINTOorders(order_id,customer_id,product_id,quantity,create_time)VALUES(p_order_id,p_customer_id,p_product_id,p_quantity,SYSDATE);UPDATEinventorySETstock=stock-p_quantityWHEREproduct_id=p_product_id;COMMIT;EXCEPTIONWHENNO_DATA_FOUNDTHENRAISE_APPLICATION_ERROR(-20002,'产品不存在');WHENOTHERSTHENROLLBACK;RAISE;ENDcreate_order;FUNCTIONget_order_status(p_order_idINNUMBER)RETURNVARCHAR2ISv_status VARCHAR2(20);BEGINSELECTstatus_nameINTOv_statusFROMorder_statusWHEREorder_id=p_order_id;RETURNv_status;EXCEPTIONWHENNO_DATA_FOUNDTHENRETURN'未知';ENDget_order_status;ENDpkg_order;改写后的版本去掉了包体，把两个过程拆成独立单元。包级变量改为自增列加时间戳组合。异常处理改为HANDLER。RAISE_APPLICATION_ERROR改为SIGNAL：
-- 迁移后：拆分为独立存储过程DELIMITER//-- 订单创建过程CREATEPROCEDUREsp_create_order(INp_customer_idBIGINT,INp_product_idBIGINT,INp_quantityINT,OUTp_order_idBIGINT)BEGINDECLAREv_stockINT;DECLAREv_existsINTDEFAULT0;-- 声明异常处理器，替代Oracle的EXCEPTIONDECLAREEXITHANDLERFORSQLEXCEPTIONBEGINROLLBACK;SIGNAL SQLSTATE'45000'SETMESSAGE_TEXT='订单创建失败';END;STARTTRANSACTION;-- 检查产品是否存在SELECTCOUNT(*)INTOv_existsFROMinventoryWHEREproduct_id=p_product_idFORUPDATE;IFv_exists=0THENROLLBACK;SIGNAL SQLSTATE'45000'SETMESSAGE_TEXT='产品不存在';ENDIF;-- 检查库存SELECTstockINTOv_stockFROMinventoryWHEREproduct_id=p_product_id;IFv_stock<p_quantityTHENROLLBACK;SIGNAL SQLSTATE'45000'SETMESSAGE_TEXT='库存不足';ENDIF;-- 生成订单号：日期+自增IDINSERTINTOorders(customer_id,product_id,quantity,create_time)VALUES(p_customer_id,p_product_id,p_quantity,NOW());SETp_order_id=LAST_INSERT_ID();-- 扣减库存UPDATEinventorySETstock=stock-p_quantityWHEREproduct_id=p_product_id;COMMIT;END//-- 订单状态查询函数CREATEFUNCTIONfn_get_order_status(p_order_idBIGINT)RETURNSVARCHAR(20)DETERMINISTICREADSSQLDATABEGINDECLAREv_statusVARCHAR(20);SELECTstatus_nameINTOv_statusFROMorder_statusWHEREorder_id=p_order_id;RETURNIFNULL(v_status,'未知');END//DELIMITER;CONNECT BY递归查询的改写。这是另一个重灾区。Oracle用CONNECT BY做树形查询，目标库要用WITH RECURSIVE替代。
-- Oracle 部门层级查询SELECTdepartment_id,department_name,parent_id,LEVELFROMdepartmentsSTARTWITHparent_idISNULLCONNECTBYPRIOR department_id=parent_id;-- 迁移后：WITH RECURSIVE递归CTEWITHRECURSIVE dept_treeAS(-- 锚点：根节点SELECTdepartment_id,department_name,parent_id,1ASlevelFROMdepartmentsWHEREparent_idISNULLUNIONALL-- 递归：子节点SELECTd.department_id,d.department_name,d.parent_id,dt.level+1FROMdepartments dINNERJOINdept_tree dtONd.parent_id=dt.department_id)SELECT*FROMdept_tree;迁移验证：数据对了才算完
改完代码只是第一步。真正的考验是数据验证。我做了三层校验。
第一层，行数对比。源端和目标端每张表的行数必须一致。用脚本批量比对：
-- 批量生成行数校验SQLSELECTCONCAT('SELECT ''',table_name,''' AS tbl, COUNT(*) AS cnt FROM ',table_name,' UNION ALL')FROMinformation_schema.tablesWHEREtable_schema='your_database'ORDERBYtable_name;第二层，抽样比对。随机抽取每条表的100行数据，逐字段对比。重点关注NUMBER转DECIMAL后的精度、日期转DATETIME后的时分秒。
第三层，业务校验。用核心业务SQL在两端分别执行，比对结果。比如订单汇总金额、客户余额、库存总数。这些数字对不上，说明迁移有问题。
实际迁移时，第三层校验帮我发现了一个隐藏问题。Oracle的NVL和MySQL的IFNULL在空字符串处理上行为不同。Oracle把空字符串当NULL，MySQL不这么认为。这导致一个汇总查询的结果差了几十万。
迁移避坑清单
别低估字符集转换的影响。Oracle源端如果是WE8MSWIN1252编码，转到UTF-8时中文可能乱码。迁移前一定要先确认两端的字符集和排序规则。我做迁移时吃过这个亏，导完数据才发现中文变成了问号。
Oracle的空字符串等于NULL，别忘记这个陷阱。这是Oracle和其他数据库最大的差异之一。VARCHAR2(10) = ''在Oracle里等同于IS NULL。迁移后如果目标库不这么处理，所有涉及空字符串判断的逻辑都要改。我搞错过一次，上线后花了半天才定位到这个问题。
存储过程里的隐式类型转换要逐一排查。Oracle的隐式类型转换比MySQL宽松得多。NUMBER和VARCHAR互相转换在Oracle里能自动完成，在目标库可能直接报错。迁移时要把所有隐式转换显式化，用CAST函数明确指定类型。
对了，迁移过程中我还了解到金仓数据库有专门的Oracle兼容模式。他们的异构数据同步软件Kingbase FlySync（简称KFS）在Oracle迁移场景下提供了自动化迁移工具，能自动识别不兼容的PL/SQL语法并给出改写建议。这对大规模迁移来说确实能节省不少前期评估时间。
不过工具归工具，最终还是要逐行验证。自动化只是辅助，不是替代。
迁移总结
异构数据库迁移不是简单的导数据。它是应用代码的翻译、数据类型的映射、业务逻辑的校验，三位一体。我的建议是：先做兼容性评估，再制定数据类型映射规则，然后逐段改写存储过程，最后做三层数据校验。顺序不能乱。
迁移完成后，至少并行运行两周。两端同时接单，比对结果。稳定后再切流量。
朋友，你在数据库迁移过程中遇到过什么坑？是数据类型对不上，还是存储过程改不完？欢迎在评论区聊聊。
我是数据库小学妹，咱们下篇见 👋
