使用UNION/UNION ALL插入数据时无法插入全部行的问题排查

结合你描述的Oracle环境场景，只插入了PART B的记录而PART A的1000条数据丢失，可能有以下几个常见原因：

• PART A的CTE查询在存储过程执行环境下实际无返回数据
  你单独运行查询时能得到1000条，但存储过程的执行上下文可能和你的会话不同：比如存储过程默认使用AUTHID DEFINER，执行者没有CTE涉及表的访问权限；或者存储过程依赖的会话变量、参数设置（比如日期格式、绑定变量值）和你手动查询时不一致，导致CTE里的过滤条件没有命中任何数据。

• PART A的所有记录与PART B的记录完全重复，被UNION去重过滤
  虽然你说PART A有1000条数据，但如果这些数据的X,Y,Z字段值全是('A','B','C')，那么UNION会自动去重，最终只保留1条（PART B的那条）。不过你提到用UNION ALL也不行，这个可能性较低，但可以手动验证下PART A的实际返回值是否真的和PART B无重复。

• 字段类型不兼容导致PART A的记录被隐式转换或过滤
  比如目标表的COLUMN1是NUMBER类型，而PART A的X是VARCHAR2类型且包含无法转换为数字的值，理论上会抛出转换异常，但如果存储过程有未显式写出的异常捕获逻辑，可能会跳过错误记录；或者隐式转换后PART A的记录变成了与PART B重复的值，被去重。

• 存储过程编译时的依赖问题
  如果CTE涉及的表在存储过程编译后发生了结构变化（比如字段被修改），存储过程可能处于无效状态，执行时重新编译若出现未被捕获的问题，可能导致PART A的查询无法正确执行。可以尝试重新编译存储过程：ALTER PROCEDURE PROC_INSERT COMPILE;

• 事务隔离级别或锁的影响
  存储过程执行时，PART A涉及的表可能被其他事务持有排他锁，导致查询无法读取到数据（Oracle默认的READ COMMITTED隔离级别下这种情况少见，但如果有长事务存在也可能发生）。可以检查执行存储过程时的数据库锁状态。

建议你先在存储过程中加一些调试逻辑，比如在INSERT前先查询PART A的记录数并输出到日志或临时表，确认存储过程执行时PART A是否真的有数据返回，这能快速定位问题所在。

内容的提问来源于stack exchange，提问作者halfwind22