Oracle 迁 PostgreSQL 的第一个坑：'' 在 Oracle 是 NULL，迁移当天数据一行不差，切换后同一条 INSERT 整批失败

下面每一行都是在两边各执行一次的结果。Oracle 一侧统一用 SQL*Plus，PostgreSQL 一侧用 psql。

Oracle 一侧用 INSERT /*+ APPEND */ 造 100 万行（4.87–5.78 s），其中 20000 行的 phone 和 email 写的是 ''。查询结果：phone IS NULL = 20000，phone = '' 为 0——'' 在写入时就变成了 NULL。段大小：表 60 MB，phone 索引 26 MB，email 唯一索引 27 MB。

导出成 CSV，用 psql 的 \copy 导进 PostgreSQL（2.79–3.25 s，heap 81 MB，phone 索引 30 MB）。核对：总行数 1000000，phone IS NULL = 20000，phone = '' 为 0。行数、NULL 数、抽样都对得上，这一步任何校验脚本都会给通过。

所以「数据迁移校验通过」和「'' 问题不存在」是两回事：Oracle 里根本存不下 ''，迁移过来的数据当然没有 ''。风险全部在切换之后的写入路径上。

模拟切换后应用继续按老习惯写数据：一条 INSERT … SELECT 写 1 万行，其中 200 行 phone 和 email 是 ''。

Oracle：0.04–0.18 s 写入 10000 行，phone IS NULL 变成 20200，phone = '' 仍为 0。唯一索引上多出的 200 个 '' 都是 NULL，不冲突。

PostgreSQL：第二个 email = '' 撞上唯一索引，报 ERROR 23505 duplicate key value violates unique constraint，Key (email)=()。这是单条语句，整批回滚，0 行写入。如果这是一个订单同步任务，表现就是「切换后某天开始整批同步失败」，日志里只有一个看不出原因的空键。

把 email 改成写 NULL、phone 仍写 '' 再跑一次，PG 写入成功，但 phone 列变成 IS NULL = 20000、= '' = 200。原来按 phone IS NULL 统计「未留电话」的报表，从切换这天起少算这 200 行，两边加起来才等于 Oracle 的 20200。

Oracle 的 B-tree 索引不存所有键列都为 NULL 的行（官方 Concepts 文档原话：does not index table rows in which all key columns are null，位图索引除外）。所以在 Oracle 上 WHERE phone IS NULL 不走单列 phone 索引：TABLE ACCESS FULL，7521–7522 个缓冲块，0.01–0.04 s。Oracle 上常见的做法是建 (phone, 0) 复合索引，让 NULL 行也进索引：建索引 0.36–0.45 s、28 MB，之后 INDEX RANGE SCAN，42 个缓冲块，约 0.00–0.01 s。

PostgreSQL 的 B-tree 会存 NULL，同样的 WHERE phone IS NULL 是 Index Only Scan，22 个缓冲块，1.75–2.05 ms。迁移时 (phone, 0) 这种为 Oracle 准备的索引可以不迁。

但如果为了兼容 '' 把查询改成 WHERE phone IS NULL OR phone = ''，计划变成 BitmapOr + Bitmap Heap Scan，10335 个缓冲块，8.6–13.0 ms，比只查 IS NULL 慢 5 倍左右。改查询是在给数据问题打补丁，数据统一之后这个代价就不用付。

PG 侧有两种常见防线：在列上加 CHECK (phone <> '') 拒收 ''；或者加 BEFORE INSERT 触发器，把 '' 用 NULLIF 转成 NULL，模拟 Oracle 的行为。我在空表上各写 20 万行（其中 2% 为 ''），每种 3 次 × 3 轮。

我的判断：切换前后用 CHECK，不用触发器。理由有两个。第一，CHECK 写入干净数据只多 5–10%，触发器多约 50%；第二，也是更重要的，CHECK 会让每一个还在写 '' 的代码路径当场报 23514，测试环境跑一遍回归就能把它们全部找出来改掉；触发器会把 '' 悄悄改成 NULL，代码路径永远不会暴露，等哪天有人绕过触发器（比如 COPY 到不带触发器的分区、换了 ETL 工具），问题又回来了。

触发器适合的场景只有一种：代码一时改不完、又必须先切换。那就把它当临时兜底，同时记日志找出写 '' 的来源，改完代码再删掉。

切换后已经写进了 '' 的表，按下面的顺序处理。本次 101 万行的表上 200 行 ''，每一步都是毫秒级；大表请在低峰执行，UPDATE 量大时分批。

迁移前在 Oracle 上无法直接找出「应用写过 ''」——它们已经是 NULL 了。能做的是列出风险最高的三类字符列：有 NULL 的可空列（num_nulls > 0）、唯一索引里的可空字符列（切换后最可能出现 23505）、NOT NULL 字符列（切换后可能进 ''）。下载区的 Oracle SQL 只查 ALL_TAB_COLUMNS / ALL_IND_COLUMNS 等字典视图，在本次测试库上准确列出了 CUST.PHONE、CUST.EMAIL（num_nulls 20000，占 2%）、唯一索引 UQ_CUST_EMAIL 和 NOT NULL 列 NICK。

num_nulls 来自统计信息，统计过旧时会不准；清单出来之后，再去代码里搜这些列的写入点，重点看表单空输入、接口默认值和 trim() 之后的结果。