去O实战：Oracle到国产数据库的类型映射、代码改写与数据校验全流程-阿里云开发者社区

大家好，我是数据库小学妹 👋

前段时间，一家制造企业找到我们，要把跑了七年的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 源端
CREATE TABLE orders (
    order_id    NUMBER(19),           -- 订单号
    amount      NUMBER(12,2),         -- 金额
    quantity    NUMBER(10),           -- 数量
    status      NUMBER(2)             -- 状态码
);

-- MySQL/国产数据库 目标端
CREATE TABLE orders (
    order_id    BIGINT,               -- 订单号，19位整数
    amount      DECIMAL(12,2),        -- 金额，保留2位小数
    quantity    INT,                  -- 数量，10位整数足够
    status      TINYINT               -- 状态码，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 读写CLOB
DECLARE
    v_clob CLOB;
BEGIN
    SELECT content INTO v_clob FROM articles WHERE id = 1;
    DBMS_LOB.APPEND(v_clob, '追加内容');
    UPDATE articles SET content = v_clob WHERE id = 1;
END;

-- 迁移后（MySQL/国产数据库）
UPDATE articles SET content = CONCAT(content, '追加内容') WHERE id = 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 原始包定义
CREATE OR REPLACE PACKAGE pkg_order AS
    PROCEDURE create_order(
        p_customer_id IN NUMBER,
        p_product_id  IN NUMBER,
        p_quantity    IN NUMBER,
        p_order_id    OUT NUMBER
    );
    FUNCTION get_order_status(p_order_id IN NUMBER) RETURN VARCHAR2;
END pkg_order;

-- Oracle 包体
CREATE OR REPLACE PACKAGE BODY pkg_order AS
    g_seq_counter NUMBER := 0;  -- 包级变量

    PROCEDURE create_order(
        p_customer_id IN NUMBER,
        p_product_id  IN NUMBER,
        p_quantity    IN NUMBER,
        p_order_id    OUT NUMBER
    ) IS
        v_stock NUMBER;
    BEGIN
        -- 检查库存
        SELECT stock INTO v_stock FROM inventory
        WHERE product_id = p_product_id;

        IF v_stock < p_quantity THEN
            RAISE_APPLICATION_ERROR(-20001, '库存不足');
        END IF;

        -- 生成订单
        g_seq_counter := g_seq_counter + 1;
        p_order_id := TO_NUMBER(TO_CHAR(SYSDATE, 'YYYYMMDD') || LPAD(g_seq_counter, 6, '0'));

        INSERT INTO orders (order_id, customer_id, product_id, quantity, create_time)
        VALUES (p_order_id, p_customer_id, p_product_id, p_quantity, SYSDATE);

        UPDATE inventory SET stock = stock - p_quantity
        WHERE product_id = p_product_id;

        COMMIT;
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            RAISE_APPLICATION_ERROR(-20002, '产品不存在');
        WHEN OTHERS THEN
            ROLLBACK;
            RAISE;
    END create_order;

    FUNCTION get_order_status(p_order_id IN NUMBER) RETURN VARCHAR2 IS
        v_status VARCHAR2(20);
    BEGIN
        SELECT status_name INTO v_status FROM order_status
        WHERE order_id = p_order_id;
        RETURN v_status;
    EXCEPTION
        WHEN NO_DATA_FOUND THEN
            RETURN '未知';
    END get_order_status;
END pkg_order;

改写后的版本去掉了包体，把两个过程拆成独立单元。包级变量改为自增列加时间戳组合。异常处理改为HANDLER。RAISE_APPLICATION_ERROR改为SIGNAL：

-- 迁移后：拆分为独立存储过程

DELIMITER //

-- 订单创建过程
CREATE PROCEDURE sp_create_order(
    IN p_customer_id BIGINT,
    IN p_product_id  BIGINT,
    IN p_quantity    INT,
    OUT p_order_id   BIGINT
)
BEGIN
    DECLARE v_stock INT;
    DECLARE v_exists INT DEFAULT 0;

    -- 声明异常处理器，替代Oracle的EXCEPTION
    DECLARE EXIT HANDLER FOR SQLEXCEPTION
    BEGIN
        ROLLBACK;
        SIGNAL SQLSTATE '45000'
            SET MESSAGE_TEXT = '订单创建失败';
    END;

    START TRANSACTION;

    -- 检查产品是否存在
    SELECT COUNT(*) INTO v_exists FROM inventory
    WHERE product_id = p_product_id FOR UPDATE;

    IF v_exists = 0 THEN
        ROLLBACK;
        SIGNAL SQLSTATE '45000'
            SET MESSAGE_TEXT = '产品不存在';
    END IF;

    -- 检查库存
    SELECT stock INTO v_stock FROM inventory
    WHERE product_id = p_product_id;

    IF v_stock < p_quantity THEN
        ROLLBACK;
        SIGNAL SQLSTATE '45000'
            SET MESSAGE_TEXT = '库存不足';
    END IF;

    -- 生成订单号：日期+自增ID
    INSERT INTO orders (customer_id, product_id, quantity, create_time)
    VALUES (p_customer_id, p_product_id, p_quantity, NOW());

    SET p_order_id = LAST_INSERT_ID();

    -- 扣减库存
    UPDATE inventory SET stock = stock - p_quantity
    WHERE product_id = p_product_id;

    COMMIT;
END //

-- 订单状态查询函数
CREATE FUNCTION fn_get_order_status(p_order_id BIGINT)
RETURNS VARCHAR(20)
DETERMINISTIC
READS SQL DATA
BEGIN
    DECLARE v_status VARCHAR(20);

    SELECT status_name INTO v_status FROM order_status
    WHERE order_id = p_order_id;

    RETURN IFNULL(v_status, '未知');
END //

DELIMITER ;

CONNECT BY递归查询的改写。 这是另一个重灾区。Oracle用CONNECT BY做树形查询，目标库要用WITH RECURSIVE替代。

-- Oracle 部门层级查询
SELECT department_id, department_name, parent_id, LEVEL
FROM departments
START WITH parent_id IS NULL
CONNECT BY PRIOR department_id = parent_id;

-- 迁移后：WITH RECURSIVE递归CTE
WITH RECURSIVE dept_tree AS (
    -- 锚点：根节点
    SELECT department_id, department_name, parent_id, 1 AS level
    FROM departments
    WHERE parent_id IS NULL
    UNION ALL
    -- 递归：子节点
    SELECT d.department_id, d.department_name, d.parent_id, dt.level + 1
    FROM departments d
    INNER JOIN dept_tree dt ON d.parent_id = dt.department_id
)
SELECT * FROM dept_tree;

迁移验证：数据对了才算完

改完代码只是第一步。真正的考验是数据验证。我做了三层校验。

第一层，行数对比。源端和目标端每张表的行数必须一致。用脚本批量比对：

-- 批量生成行数校验SQL
SELECT CONCAT('SELECT ''', table_name, ''' AS tbl, COUNT(*) AS cnt FROM ', table_name, ' UNION ALL')
FROM information_schema.tables
WHERE table_schema = 'your_database'
ORDER BY table_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函数明确指定类型。

对了，迁移过程中我还了解到KES有专门的Oracle兼容模式。他们的异构数据同步软件Kingbase FlySync（简称KFS）在Oracle迁移场景下提供了自动化迁移工具，能自动识别不兼容的PL/SQL语法并给出改写建议。这对大规模迁移来说确实能节省不少前期评估时间。

不过工具归工具，最终还是要逐行验证。自动化只是辅助，不是替代。

迁移总结

异构数据库迁移不是简单的导数据。它是应用代码的翻译、数据类型的映射、业务逻辑的校验，三位一体。我的建议是：先做兼容性评估，再制定数据类型映射规则，然后逐段改写存储过程，最后做三层数据校验。顺序不能乱。

迁移完成后，至少并行运行两周。两端同时接单，比对结果。稳定后再切流量。

朋友，你在数据库迁移过程中遇到过什么坑？是数据类型对不上，还是存储过程改不完？欢迎在评论区聊聊。

我是数据库小学妹，咱们下篇见 👋

去O实战：Oracle到国产数据库的类型映射、代码改写与数据校验全流程

为什么说异构迁移最难的不是数据，而是"习惯"？

数据类型映射：从NUMBER到VARCHAR2，逐一对照

存储过程改写：PL/SQL到标准SQL的翻译过程

迁移验证：数据对了才算完

迁移避坑清单

迁移总结

数据库

热门文章

最新文章

相关电子书