Oracle 老兵转战 PostgreSQL：这些雷你踩过几个？
青学会会长约 4 分钟在数据库国产化的大潮中，将数据定义语言从 Oracle 迁移到 PostgreSQL 往往是第一场硬仗。这不仅仅是语法的简单查找替换，更是一次思维方式的转变。
有太多因为忽视数据类型差异或分区机制不同而导致的性能问题。本文将基于 PostgreSQL 15 以上版本，深入剖析迁移中的核心痛点，并提供生产级的转换案例。
一 数据类型的精准映射
Oracle 的数据类型设计偏向大一统，而 PostgreSQL 的类型系统则更加严谨和丰富。
1 数值类型的避坑指南
误区：将所有 Oracle NUMBER 都转为 PG NUMERIC。
最佳实践：
NUMBER(9) 及以下转为 INTEGER，4 字节存储，性能更好 NUMBER(18) 及以下转为 BIGINT，8 字节存储，适合 ID 字段 涉及金额小数 NUMBER(10, 2) 转为 NUMERIC(10, 2)，保持高精度
2 时间类型的致命差异
Oracle 的 DATE 包含时分秒，而 PG 的 DATE 只是日期。
修正：必须将 Oracle DATE 迁移为 PG 的 TIMESTAMP 或 TIMESTAMPTZ（带时区，推荐使用）。
3 字符类型的优化建议
在 PostgreSQL 中，CHAR(n)、VARCHAR(n) 和 TEXT 在底层存储上几乎无性能差异。
建议：不再纠结长度，大胆使用 TEXT 或 VARCHAR，除非有严格的业务长度限制需求。
二 案例实战 核心交易表的 DDL 转换
我们以一张电商系统的订单主表为例，包含自增主键、金额、状态和时间。
Oracle 原版 DDL
CREATETABLE orders (
order_id NUMBER(20) NOTNULL,
order_no VARCHAR2(64CHAR) NOTNULL,
user_id NUMBER(19) NOTNULL,
total_amt NUMBER(12, 2) DEFAULT0,
statusCHAR(1) DEFAULT'0',
created_at DATEDEFAULTSYSDATE,
remark CLOB,
CONSTRAINT pk_orders PRIMARY KEY (order_id)
);
CREATESEQUENCE seq_orders_id STARTWITH1INCREMENTBY1;
PostgreSQL 进阶版 DDL
CREATETABLE orders (
order_id BIGINTGENERATEDBYDEFAULTASIDENTITY PRIMARY KEY,
order_no TEXTNOTNULL,
user_id BIGINTNOTNULL,
total_amt NUMERIC(12, 2) DEFAULT0,
statusCHAR(1) DEFAULT'0',
created_at TIMESTAMPTZ DEFAULTCURRENT_TIMESTAMP,
remark TEXT
);
CREATEUNIQUEINDEX uk_orders_no ON orders(order_no);
专家点评：注意 GENERATED ... IDENTITY 是 PG 10 引入的标准写法，比旧式的 SERIAL 类型更健壮，权限管理也更清晰。
三 分区表的迁移策略
Oracle 的分区功能极其强大，而 PostgreSQL 采用的是声明式分区。
场景 按月存储的交易流水表
Oracle 方案
CREATETABLE trade_logs (
log_id NUMBER,
trade_date DATE,
contentVARCHAR2(2000)
)
PARTITIONBYRANGE (trade_date) INTERVAL (NUMTOYMINTERVAL(1, 'MONTH'))
(
PARTITION p_init VALUESLESSTHAN (TO_DATE('2024-01-01', 'YYYY-MM-DD'))
);
PostgreSQL 方案
PG 原生不支持自动创建分区，我们需要显式创建子表，或者使用 pg_partman 插件。
基础原生写法：
-- 创建父表
CREATETABLE trade_logs (
log_id BIGINTNOTNULL,
trade_date TIMESTAMPTZ NOTNULL,
contentTEXT
) PARTITIONBYRANGE (trade_date);
-- 手动创建子表
CREATETABLE trade_logs_202401 PARTITIONOF trade_logs
FORVALUESFROM ('2024-01-01') TO ('2024-02-01');
CREATETABLE trade_logs_202402 PARTITIONOF trade_logs
FORVALUESFROM ('2024-02-01') TO ('2024-03-01');
-- 在分区键上建立索引
CREATEINDEX idx_trade_logs_date ON trade_logs(trade_date);
关键差异点：
主键限制：在 PG 分区表中，主键或唯一约束必须包含分区键 维护成本：PG 需要通过 CronJob 或 pg_partman 扩展来预创建未来的分区
四 容易被忽视的细节差异
1 空字符串与 NULL
这是迁移中最隐蔽的雷区。
Oracle 中空字符串等价于 NULL PostgreSQL 中空字符串是长度为 0 的字符串，NULL 是空值，它们截然不同 影响：业务代码中 IS NOT NULL 的判断逻辑在迁移后可能会失效
2 大小写敏感性
Oracle 对象名默认大写存储，查询时不敏感 PostgreSQL 对象名默认转为小写存储 建议：迁移时统一改为蛇形小写命名法（如 order_id），避免使用双引号
3 同义词的处理
Oracle 常用同义词来访问跨 Schema 对象。PG 原生不支持同义词。
方案：使用 search_path 也就是 Schema 搜索路径来解决对象查找问题。
五 总结与建议
从 Oracle 到 PostgreSQL 的迁移，本质上是从商业黑盒到开源标准的迁移。
数据类型：拥抱 TEXT、NUMERIC 和 TIMESTAMPTZ 自增列：放弃 Sequence，使用 IDENTITY 分区表：适应声明式分区，引入运维自动化工具 思维方式：警惕空字符串和 NULL 的陷阱
建议使用开源工具如 Ora2Pg 进行初步的 Schema 转换评估，它能自动识别 90% 的 DDL 差异，为您生成一份高质量的迁移报告。