PostgreSQL 教程: 迁移 Oracle 数据库时，底层设计差异的影响

八月 12, 2026

摘要：在本教程中，我们会介绍将 Oracle 迁移至 PostgreSQL 时，数据库底层设计差异带来的影响。

核心背景与概述

在迁移初期，团队处理了许多基础的语法转换，并发现了隐藏的逻辑陷阱：

1. 空值函数替换 (NVL vs COALESCE)

2. 类型转换 (隐式 vs 显式)

差异：Oracle 具备极强的隐式类型转换能力（例如字符串直接加减）；而 PostgreSQL 要求严格的显式类型转换。
方案：需要在代码中明确添加 Type Cast（类型转换）。团队还发现，对于特定的需求（例如在整数末尾补两个零），与其使用“转字符串拼接再转整数”的复杂操作，不如直接“乘以100”来得高效简洁。

3. 条件匹配陷阱 (DECODE vs CASE)

差异：Oracle 的 DECODE 函数允许将 NULL 与 NULL 进行等值匹配；而在 PostgreSQL 中替换为 CASE 语句时，标准的 NULL = NULL 结果为 false。
初级方案：使用 CASE WHEN ... IS NULL 或 IS NOT DISTINCT FROM 替代，确立正确的空值判断逻辑。
性能危机与最终方案：在进行表连接（JOIN）时，由于 PostgreSQL 查询规划器（Query Planner）目前无法为 IS NOT DISTINCT FROM 充分利用索引，导致性能极差。为了追求极致性能，团队采用了一种变通方案：将比较的 NULL 值转换为特定的占位字符串（如 ||NULL||）。这样就可以使用标准的等号（=）进行比较并建立普通索引，大幅提升了查询效率。

两种数据库在处理数值（尤其是除法和高精度计算）时表现截然不同，这在涉及财务结算的系统中尤为致命。

整数除法差异：

精度管理机制对比：

Oracle：只有一个精确的数值类型（NUMBER），在进行不精确计算时，会自动填满其支持的最大精度（约 39-40 位有效数字）。
PostgreSQL：最大支持 1000 位精度。出于性能考量，无法每次都填满。对于计算结果，它高度依赖于操作数的声明精度（Scale）。如果不显式指定，可能导致财务数据精度丢失。

解决方案：为避免在代码各处手动添加易遗漏的类型转换，团队直接在表结构定义阶段出击，将所有相关数值字段统一修改为高精度类型 NUMERIC(52, 40)，从根本上杜绝了计算错误。

这是整个迁移过程中最核心的性能与架构挑战。

业务场景：每月需对一张约 2 亿条记录的大表进行滚动处理。客户提交的数据往往不完整，需将约 1 亿条未完成的记录 UPDATE（更新）至下一个月。

Oracle 的表现 (In-place Update)：

PostgreSQL 的表现 (MVCC 多版本并发控制)：

常规维护手段的局限性：

最终破局策略：调整业务逻辑

结论：在 PostgreSQL 中，必须尽量避免大规模的批量 UPDATE。
改造：团队摒弃了“每月搬运海量未完成数据”的做法。改为默认保留状态为空，只有当数据确实“已完成”时，才去 UPDATE 那一小部分完成的记录。这一业务逻辑的转换不仅秒解了性能危机，也彻底避免了表膨胀。

根据本次实战，团队总结了异构数据库迁移的标准步骤：

严格是件好事：Oracle 对很多不规范的 SQL 写法（Bad Practices）包容度极高。PostgreSQL 相对严格，这种“严格”使得旧代码中的隐患暴露无遗，客观上倒逼团队修复了大量历史技术债，提升了代码质量。
迁移工具选择：团队并没有过度依赖自动化转换工具（如 ora2pg），而是选择手动迁移 Schema、使用自定义脚本进行数据迁移，以此更好地处理字段重命名等定制化需求。