minus能快速发现行级差异，但必须配对使用、注意null和列顺序，不能替代结构校验；它是oracle原生集合操作，由c层引擎执行，比pl/sql循环快10倍以上，底层走union-all+sort unique+merge join anti路径。
直接结论：minus能快速发现行级差异，但必须配对使用、注意null和列顺序，不能替代结构校验。
为什么MINUS比逐行循环快得多
MINUS是Oracle原生集合操作，由C层引擎直接执行，不经过PL/SQL解释器。它自动去重、排序、逐字段比对，单条SQL就能完成全表扫描+差集计算。而用游标循环读取再逐行比较，不仅逻辑复杂，还会因上下文切换和PL/SQL开销拖慢10倍以上。
- MINUS底层调用的是
UNION-ALL+SORT UNIQUE+MERGE JOIN ANTI优化路径，19c对大表做了并行和内存排序增强 - 不要在MINUS子句里写
SELECT *——列顺序错位会导致误报；必须显式列出所有列且顺序一致 - NULL值在MINUS中视为“相等”，所以
A.COL1 = NULL和B.COL1 = NULL会被当成同一行，这是正确行为，不是bug
用存储过程封装MINUS对比的实操要点
把MINUS逻辑包进存储过程，是为了复用、加日志、统一权限控制，不是为了“看起来高级”。关键在参数设计和错误兜底。
- 输入参数必须是
IN VARCHAR2，不能用%TYPE——表名是对象名，不是数据类型 - 用
EXECUTE IMMEDIATE拼接SQL时，务必用DBMS_ASSERT.SQL_OBJECT_NAME校验表名，防SQL注入 - 捕获
ORA-00942: table or view does not exist异常，避免一个表不存在就中断整个流程 - 结果建议写入临时表（如
diff_result），而不是只DBMS_OUTPUT.PUT_LINE——后者在批量调用时不可见
MINUS对比必须配对使用的两个方向
只跑SELECT * FROM A MINUS SELECT * FROM B只能看到A有B没有的行，漏掉“B有A没有”和“同主键但字段值不同”的情况。真实差异必须靠双向MINUS合集判断。
- 方向一：
SELECT * FROM A MINUS SELECT * FROM B→ 得到“删除或修改前的旧值” - 方向二：
SELECT * FROM B MINUS SELECT * FROM A→ 得到“新增或修改后的最新值” - 合并时别用
UNION ALL——重复行会干扰判断；用UNION去重后加标记列（如src_flag VARCHAR2(1)）区分来源 - 如果表有主键，建议先用
WHERE EXISTS限定主键交集，再对交集内行做MINUS，避免全表扫描浪费
容易被忽略的兼容性陷阱
19c默认开启OPTIMIZER_FEATURE_ENABLE='19.1.0'，但MINUS行为本身没变。真正出问题的地方在隐式类型转换和字符集。
- 如果A表某列为
VARCHAR2(10 CHAR)、B表为VARCHAR2(10 BYTE)，MINUS可能因截断导致假差异——必须提前用DUMP()检查实际字节长度 - 跨库对比（如11g源库 vs 19c目标库）时，
NLS_COMP和NLS_SORT设置不一致会让中文排序结果不同，MINUS误判为“不一致行” - 19c对
LONG列已完全弃用，若老表含LONG，MINUS会直接报ORA-00997: illegal use of LONG datatype，必须先转成CLOB再比
真正卡住人的往往不是MINUS语法，而是没意识到：它只回答“哪些行不一样”，从不告诉你“为什么不一样”。主键缺失、触发器延迟生效、未提交事务、甚至客户端NLS_DATE_FORMAT差异，都可能让MINUS结果看似异常。动手前先确认两边数据已静默、无DML、时区和字符集一致。否则，你调得越细，离真相越远。
