1. INSERT INTO 的基本语法与三种最常用写法
先说明白一件事：Oracle 11g 里的 INSERT INTO，很多人觉得太简单，不就是往表里塞数据吗？但实际项目里，大量莫名其妙的报错、性能问题，甚至数据错乱，根源往往就藏在 INSERT 的细节里。这篇文章我以 Oracle 11g 为基础环境，把 INSERT INTO 的常见用法、容易踩的坑、以及实战经验全部过一遍，内容尽量贴近真实开发场景。
1.1 完整列名的标准写法
这是最推荐、也是可读性和安全性最高的写法：
INSERT INTO emp (empno, ename, job, mgr, hiredate, sal, comm, deptno) VALUES (1001, '张伟', 'CLERK', 7839, TO_DATE('2024-03-15', 'YYYY-MM-DD'), 3500, NULL, 10);为什么推荐显式写全列名？
- 表结构变化时（比如新增列、调整列顺序），SQL 语句不会因为列顺序改变而插入错位置。
- 别人读代码时，一眼就能看出每个值对应哪个字段。
- 可以只插入部分字段，其余列依赖默认值或自动填充。
在实际开发中，我见过大量INSERT INTO ... VALUES不写列名的代码，表结构一调整，数据就插到了错误的列上。这不是危言耸听，在生产和测试环境里都真实发生过。
1.2 省略列名的危险写法
INSERT INTO emp VALUES (1002, '李娜', 'SALESMAN', 7698, SYSDATE, 3000, 800, 30);这种写法要求 VALUES 里的值必须与表的物理列顺序一一对应，而且不能省略任何列。Oracle 查询列顺序的底层逻辑是数据字典里的COLUMN_ID，如果你查看表结构时用了SELECT *，看到的是字典顺序，但后续 ALTER TABLE 追加的新列会排在最后。
所以问题来了：只要表结构发生过 DDL 变更，省略列名的 INSERT 就可能全部错位。我在实际发生过的案例中，有同事在新环境里执行了一段旧脚本，把所有数字都插进了字符列，插入时 Oracle 做了隐式转换没报错，但数据逻辑全乱了。真到了这一步，排查的难度远大于你省下的那几个字符。
建议大家把省略列名的写法只用在一次性临时脚本里，而且要确保非常确定表结构没变过。
1.3 用子查询从一张表插入另一张表
这是 INSERT 用得最频繁也最实用的场景，语法长这样：
INSERT INTO emp_history (empno, ename, hiredate, sal) SELECT empno, ename, hiredate, sal FROM emp WHERE deptno = 20;这种 INSERT ... SELECT 的写法有几个特点：
- 目标表的列清单与 SELECT 列表在数量、数据类型上必须匹配，否则会得到
ORA-00947 值不足或ORA-00913 值过多。 SELECT里可以使用任意子查询、关联、集合运算等，本质上是把查询结果集一次性写入目标表。- 如果你只是想复制表结构加数据，可以用
CREATE TABLE t2 AS SELECT ...（缩写 CTAS），但注意 CTAS 不会复制原表的主键、约束、索引、默认值，只会带列定义和非空约束。业务表之间做数据归档、历史数据迁移，推荐用 INSERT ... SELECT 而不是 CTAS。
这让我想起另一个高频场景——生成大量测试数据。有时候需要往表里插入一批造出来的数据，单值 INSERT 一条条写太麻烦。可以用子查询配合递归查询：
INSERT INTO test_data (id, val, create_time) SELECT LEVEL, '测试数据' || LEVEL, SYSDATE FROM dual CONNECT BY LEVEL <= 10000;这个写法一次插 1 万条，在 Oracle 11g 下跑得飞快。CONNECT BY 在 SQL 里不只是层级查询，用来生成数据行也很好用。不过要注意，大量生成数据时不要超过内存限制，如果级别很深造成性能问题，考虑改用多行插入或 PL/SQL 循环。
1.4 多表插入：INSERT ALL
Oracle 从 9i 开始支持INSERT ALL，能把同一份数据并行插入多张表。语法上有两个方向：无条件插入和有条件插入。
无条件插入：
INSERT ALL INTO dept_log (deptno, dname) VALUES (deptno, dname) INTO dept_backup (deptno, dname, create_date) VALUES (deptno, dname, SYSDATE) SELECT deptno, dname FROM dept;有条件插入：
INSERT ALL WHEN sal >= 3000 THEN INTO high_sal_emp (empno, ename, sal) VALUES (empno, ename, sal) WHEN sal < 3000 THEN INTO low_sal_emp (empno, ename, sal) VALUES (empno, ename, sal) SELECT empno, ename, sal FROM emp;还有INSERT FIRST，它和INSERT ALL的区别在于：ALL 会对每一行执行所有满足条件的 WHEN 子句，而 FIRST 只执行第一个满足条件的 WHEN。比如一行同时又满足多个条件，用 ALL 会插入多张表，用 FIRST 只会进第一张表。这个差异在实际报表拆分、数据分发场景里非常关键，写之前一定想清楚业务想要哪种效果。
我常用 INSERT ALL 做的一个事情是：把一张大表按分区条件或业务维度拆分为多张表。比如订单表按年份拆成多张历史表，只需要读一次大表，就能分发到不同表里，比逐条 INSERT 或者多次读源表高效很多。但用的时候要注意事务的一致性和提交时机，这一点我后面专门展开讲。
2. Oracle 11g 里 INSERT 最容易踩的数据类型坑
到了实际开发里，INSERT 卡壳的地方基本不是语法本身，而是数据类型、隐式转换、默认值处理这三类问题。这一节我把 Oracle 11g 特有的细节梳理清楚，很多坑我都是自己踩过之后才彻底明白。
2.1 空字符串就是 NULL，这不是写错
在 Oracle 里，空字符串''会被自动当作 NULL 处理。这一点和很多其他数据库完全不同。如果你执行：
INSERT INTO emp (ename, sal) VALUES ('', 5000);你插入的不是一个长度为 0 的空字符串，而是 NULL。对于允许 NULL 的列，这没什么；但对于 NOT NULL 的列，直接报ORA-01400 无法将 NULL 插入。
放到业务里，这个问题非常隐蔽。比如前端页面提交一个空表单，后端拿到一个空字符串，你以为插入的是空字符串，实际上数据库里落的是 NULL。等后续查询统计就会发现：怎么COUNT(字段)不对？因为 NULL 不参与 COUNT 计数。我处理过的很多脏数据问题，源头就是项目组里有人不知道 Oracle 的这个特性。
如果你确实想把"空字符串"当成一种可区分状态来存，那就不能用 VARCHAR2 硬扛，而是要把''转成别的标识值，比如放一个特殊标记字符，或者把字段设计成带默认值的状态列。
2.2 日期插入：三种写法，只有一个最稳
Oracle 11g 中插入日期，最容易栽跟头的是 NLS 会话设置。默认的日期格式通常受NLS_DATE_FORMAT影响，很多环境默认是DD-MON-RR，所以下面这几种写法在不同的环境里结果完全不同：
-- 写法一：依赖会话格式，危险 INSERT INTO emp (hiredate) VALUES ('2024-03-15'); -- 写法二：SQL 标准字面量，稳定推荐 INSERT INTO emp (hiredate) VALUES (DATE '2024-03-15'); -- 写法三：TO_DATE 指定格式，也稳定且灵活 INSERT INTO emp (hiredate) VALUES (TO_DATE('2024-03-15', 'YYYY-MM-DD'));先说写法一：'2024-03-15'是个字符串，Oracle 要执行隐式转换，它按照当前会话的NLS_DATE_FORMAT去解析。有人电脑上日期格式是YYYY-MM-DD，有人是DD-MON-RR，同一段 SQL，在一个环境能跑，在另一个环境直接报ORA-01843 无效的月份。开发机没问题、测试生产就挂的经典问题，多半就是这种隐式转换造成的。
写法二和写法三都测了，在 11g 上都能稳定运行。如果带着时分秒，就老老实实写方式三：TO_DATE('2024-03-15 13:20:00', 'YYYY-MM-DD HH24:MI:SS')。
这里还有个很容易被忽略的点：Oracle 的 DATE 类型本身就包含时分秒，不是其他数据库那样 DATE 只存日期。所以在 Oracle 里插入DATE '2024-03-15'，时分秒部分自动是 00:00:00。如果你要存到秒粒度，直接用 DATE 就够了；要到微秒或者纳秒级，才需要考虑 TIMESTAMP 类型。
2.3 数字和字符串的隐式转换，以及引号问题
数字列插入字符串在 Oracle 里一般不会报错，比如INSERT INTO emp (sal) VALUES ('3500')会被隐式转换成数字。但这类代码不值得提倡，因为一旦字符串里混入了非数字字符，比如'35A00'，就是ORA-01722 无效数字。运行时错误加上不同版本的转换规则差异，尽量在应用层就规范好类型。
字符列里单引号的处理也有讲究。SQL 标准里，字符串中的单引号用两个单引号转义：
INSERT INTO emp (ename) VALUES ('O''Brien');这个字符串的实际内容是O'Brien。如果有人在 Oracle 下习惯性地用反斜杠\'来转义，那是不行的，反斜杠会被当普通字符存进去。这是一个特别常见的混淆点，尤其是那些从 MySQL 转过来的开发者，SQL 层面 MySQL 默认也支持反斜杠转义，Oracle 不支持。这点在 Oracle 11g 里要格外注意。
扩展一个相关技巧：如果你要动态拼 SQL，把字符串插入语句拼出来时，同样要做单引号转义，否则拼出来的 SQL 语法就错了。这也是为什么实际项目里推荐使用绑定变量，而不是拼字符串——既避免引号问题，也避免 SQL 注入风险。
2.4 CHAR 与 VARCHAR2 的差异，插入时的隐形坑
CHAR 是定长字符串，插入时如果长度不足，Oracle 会用空格自动补全。INSERT INTO t (code) VALUES ('A');如果 code 是 CHAR(10)，实际存储的是'A' + 9 个空格。这在查询比较的时候会带来很多怪异问题，比如：
SELECT * FROM t WHERE code = 'A';如果连接列的字符集不同，或者列一端是 CHAR 一端是 VARCHAR2，Oracle 的字符串比较规则会把空格补齐后再比较，结果可能出乎意料。更麻烦的是，当 CHAR 和 VARCHAR2 做 join 时，VARCHAR2 的值会被补空格到 CHAR 的长度，不仅可能匹配不上业务期望的记录，还会隐式增加 CPU 和 IO 消耗。我在做数据清洗时，就经常需要对 VARCHAR2 字段RTRIM()之后才做关联，就是为了绕开 CHAR 补齐空格的逻辑。
插入的时候就要想清楚：能选 VARCHAR2 就别用 CHAR，不要在源头上制造一批右填充空格的数据。如果你在维护旧系统，无法改表结构，也至少要做到 INSERT 的时候主动把字段值处理干净，比如RTRIM()后再入库。
顺便说一个列长度的问题，Oracle 11g 的 VARCHAR2 最大长度是4000 字节（注意是字节，不是字符），如果数据库字符集是 UTF-8，一个汉字占 3 个字节，那 4000 字节最多存 1000 多个汉字。插入超出长度就会报ORA-01401 插入的值对于列过大，或者ORA-12899 值太大。这里真正的坑在于：表中定义的是字节长度，代码里是按"字数"做校验的。一个用户在界面上输入了 1300 个汉字，后端校验没超长，直接插库就报 12899。处理策略很简单：应用层校验按字节数来，或者干脆在数据库层做一个长度触发器兜底。
3. 默认值、约束和事务：INSERT 的三道隐形关卡
3.1 默认值只有在"省略列"或"显式用 DEFAULT"时才生效
很多人一说到表里有默认值，就想当然认为"只要 INSERT 的时候不给这个字段赋 NULL，它就会自动填默认值"。这个理解是错的。
Oracle 的行为是：如果你在 INSERT 的列清单中省略了该列，Oracle 才会使用默认值；如果你显式给NULL或者''，默认值不会生效，直接写进去的是 NULL。
看个例子：
CREATE TABLE t_user ( id NUMBER PRIMARY KEY, uname VARCHAR2(30), status VARCHAR2(1) DEFAULT 'A', reg_time DATE DEFAULT SYSDATE ); -- 情形一：省略 status 和 reg_time 列，默认值生效 INSERT INTO t_user (id, uname) VALUES (1, '小明'); -- 情形二：显式插入 NULL，默认值不会生效 INSERT INTO t_user (id, uname, status, reg_time) VALUES (2, '小红', NULL, NULL);情形二的结果很让人头疼：status是 NULL，reg_time是 NULL。如果你的查询统计里写了WHERE status = 'A'，这条记录就永远找不到了。
这也是我在 Review 代码时经常抓的问题点。比这个更隐蔽的情况是：某些 ORM 框架会在 INSERT 语句中带上所有字段，哪怕是 NULL 也一并带上，导致数据库里大量记录虽然有默认值设定，却全是 NULL。到了做数据统计的时候，GROUP BY 出来的结果和业务预期完全对不上。解决方案有两个方向：让 ORM 配置只插入非空字段；或者建表时给列加上 NOT NULL 约束，从物理层面阻止脏数据进来。
3.2 约束先于语句提交生效，违反即报错
INSERT 语句执行时，Oracle 会逐条操作并立刻检查约束（NOT NULL、唯一约束、主键、外键、CHECK），发现违反马上报错，并且当前语句自动回滚。需要注意，语句级回滚不等于事务回滚：报错的只是这条 SQL，之前已经执行的 INSERT、UPDATE、DELETE 都还在你的事务中，可以继续操作，也可以整体 ROLLBACK。
这里常见的问题场景来自于主键冲突：ORA-00001: 违反唯一约束 (XX.PK_XXX)。很多人一看到这个报错就觉得是数据重复了，其实也可能是并发下两个会话使用相同的序列值，或者主键列本身有数据被手工插入过。排查的思路是：先查dba_constraints和dba_cons_columns，确认约束字段；再查当前表的最大键值，对比你即将插入的键值。如果表 A 的主键用的是序列 SEQ，而曾经有人直接手工插了一个大值，序列值还小于这个值，那后续的所有 INSERT 都会撞唯一约束，这几乎是每个 Oracle 项目里必现一次的经典场景。
解决办法不复杂：手工插入后，把序列重置到超过当前最大值的位置，用 PL/SQL 循环调整序列的方式很多，关键是排查时要有这个意识，避免白白重启应用还找不到原因。
3.3 Oracle 11g 事务机制：INSERT 和 DDL 提交的坑
Oracle 默认隔离级别是READ COMMITTED，一个会话里执行 INSERT 之后，不执行 COMMIT 的话，其他会话是看不到这条数据的（准确说，在其他会话中查询不到，未提交数据只能当前会话可见）。
这里隐含着两个很现实的问题：
- 如果一个 INSERT 之后你执行了一个
CREATE TABLE、ALTER TABLE、DROP TABLE之类的 DDL 语句，Oracle 会自动隐式提交当前事务。也就是说你之前 INSERT 的数据会被强制 COMMIT，之后想 ROLLBACK 也回不去了。这是 Oracle 事务机制和 MySQL InnoDB 很大的区别，我在开发团队里不止一次见过有人写完 INSERT 后顺手加了个索引，然后把整个批量导入脚本的"可回滚性"弄丢了。 - 长事务带来锁和回滚段膨胀：如果一条 INSERT 之后长时间不提交，被修改的行上的锁会一直持有，其他会话对这些行的 UPDATE、DELETE 操作会被阻塞。如果前端代码里面每次 INSERT 后不主动 COMMIT，靠连接池归还连接时隐式提交，看起来"没问题"，但一旦连接在事务中途归还或断线，数据状态就不可控了。
我的实践经验是：在程序代码里，每次 INSERT（或每个业务事务）都要有明确的 COMMIT 或 ROLLBACK 分支，不要依赖连接池或框架做隐式提交。对于批处理场景，还要注意提交频率，这个我下一节详细讲。
回滚段（UNDO segment）保存的是旧值，INSERT 的回滚信息其实就是记录插入行的 rowid。事务越大，回滚信息占用越多，如果回滚段不足，大批量插入时会报ORA-01555或ORA-30036。这类问题在 Oracle 11g 的自动管理模式下不算常见，但大批量插入前还是建议检查一下UNDO_TABLESPACE的空间。
3.4 自增字段？Oracle 11g 没有 AUTO_INCREMENT
这是个老生常谈但永远有人搞错的点。Oracle 11g 不支持 MySQL 那种AUTO_INCREMENT列属性，实现自增主键的主流做法是SEQUENCE + 触发器，或者直接在代码里调用序列。
CREATE SEQUENCE seq_emp_id START WITH 1 INCREMENT BY 1 NOCACHE; CREATE OR REPLACE TRIGGER trg_emp_id BEFORE INSERT ON emp FOR EACH ROW BEGIN SELECT seq_emp_id.NEXTVAL INTO :NEW.empno FROM dual; END;有几点注意事项：
- 触发器方式的好处是应用层不用关心主键生成，INSERT 语句里不用写 empno 也自动填充。
- 序列的 NOCACHE 和 CACHE 30 之类的性能差别，主要体现在并发高的情况下。CACHE 会预先分配一段序列号，掉电或实例重启后会跳号；NOCACHE 不会跳号，但每次 NEXTVAL 都要做字典更新，在高并发插入场景下会成为热点竞争。
- 在 11g 里，如果你用
INSERT INTO emp SELECT ...从另外一张表灌数据，同时主键序列和触发器还在，要特别注意触发器是否会对每一行执行，如果是，批量场景下性能会遭到明显影响。大批量迁移时，我通常建议先把目标表上的主键触发器停掉，导入完成后重新打开。
还有个习惯问题：插入语句中最好写全主键列，即使触发器会自动生成主键，显式写上也不会冲突，只是那部分代码看起来冗余。关键是别在主键列上直接写NULL或者0，前者会让触发器接管，后者可能会撞唯一约束。
4. 大批量 INSERT 的性能调优与提交策略
聊到性能，很多开发者在 INSERT 上其实没太受过系统训练。这里我把实际系统中验证过的高频技巧和节奏整理出来，按"从易到难"的顺序说明。
4.1 多条单行 INSERT：用绑定变量批量提交
如果你的业务是一次性插入几千条数据，最简单的做法是循环执行单条 INSERT。在代码层（比如 Java 的 JDBC）里，关键在于使用 PreparedStatement 绑定变量复用，而不是每次拼一条新 SQL。
JDBC 层面批量插入 Java 代码示意：
Connection conn = getConnection(); String sql = "INSERT INTO emp (empno, ename, sal, deptno) VALUES (?, ?, ?, ?)"; PreparedStatement ps = conn.prepareStatement(sql); conn.setAutoCommit(false); for (int i = 0; i < list.size(); i++) { ps.setLong(1, list.get(i).getEmpno()); ps.setString(2, list.get(i).getEname()); ps.setDouble(3, list.get(i).getSal()); ps.setLong(4, list.get(i).getDeptno()); ps.addBatch(); if (i % 500 == 0) { ps.executeBatch(); conn.commit(); } } ps.executeBatch(); conn.commit();这个做法的核心逻辑是：降低硬解析次数。Oracle 对 SQL 的执行要经历解析、绑定、执行等阶段。大量 SQL 文本完全相同，只是绑定变量的值不同，就能命中游标缓存，避免硬解析。硬解析在 CPU 和锁竞争上的开销远比想象中高，尤其在并发插入场景，library cache lock等待就是这么来的。
提交频率的平衡点：不要每条都 commit，也不要插入 10 万行才 commit 一次。前者频繁产生 redo 和事务提交开销；后者导致 undo 膨胀，且单次回滚段占用过久。我的经验值是500~1000 行提交一次，同时 commit 之前算好这批数据量大概在几十 MB 级别，回滚段空间足够，锁的持有时间也短。
另外要注意executeBatch()在提交前只是批量发送到数据库，不是自动提交。很多新手以为 addBatch 就是提交了，结果一断电，发现一条数据都没进库，白跑几小时。这个在项目里真发生过。
4.2 直接路径插入：APPEND 是一把双刃剑
INSERT /*+ APPEND */ INTO t SELECT ...这个是 Oracle 特有的、绕过缓冲区直接写入数据文件的优化手段，速度非常可观。它和普通 INSERT 最大的区别是不写 undo（准确说大幅减少 undo 写入），直接把新数据块追加在表段末尾。
使用场景和限制：
- 适用于大批量 SELECT 导数据，几百 GB 数据迁移场景简直像是开了挂。
- 执行 APPEND 时，表上不能有其他活动事务，否则会报
ORA-00054 资源正忙。 - 在 11g 中，使用 APPEND 之后，在 COMMIT 之前，其他会话不能对该表做查询或 DML（精确说会等待或报错），因为数据还没被真正落盘，Oracle 给表加了排他锁级别的保护。
还有一个真实开发中容易掉进去的坑：INSERT /*+ APPEND */在高版本和 11g 上的事务行为有差异，但无论如何，它都不是一个适合"在线业务"的插入方式。它适合离线批量任务，比如凌晨跑数据同步、ETL。如果在线系统误用了，很容易造成业务表上的应用大面积锁死。我见过有人把一个常规的归档任务突然加上了 APPEND hint，结果白天跑的时候整个订单表都查不了，报警电话都打到我这里来了。
4.3 索引和约束对插入速度的影响
索引对 INSERT 的拖累，不是索引本身生成时多慢，而是每插入一行，B-Tree 索引要维护，遇到不合适的索引设计可能触发分裂或过度块竞争。约束同理：主键和外键约束在每行插入时都要做存在性检查。
一次批量导入的经典流程是：
-- 1. 先禁用外键约束，或者直接 drop 索引 ALTER TABLE emp DISABLE CONSTRAINT FK_DEPTNO; -- 2. 执行大批量 INSERT INSERT INTO emp SELECT ...; -- 3. 重新启用约束，并重建索引 ALTER TABLE emp ENABLE CONSTRAINT FK_DEPTNO;注意，ENABLE 一个被 DISABLE 的约束时，Oracle 会先验证存量数据。如果表里有违反约束的数据，ENABLE 会失败，得用ENABLE NOVALIDATE跳过存量校验，但这样约束就只对新数据生效。业务上要小心，你等于承认表里可能有一批老数据是不符合规则的。在这种取舍面前，要在运维文档里写清楚，否则后续同事接手时分析数据，查不到任何提示，纯靠猜。
索引禁用和重建的逻辑其实也分情况：如果一次性插入的数据量达到表数据的 10% 以上，先删索引再插入、然后重建索引，往往比带着索引插快得多。如果只是天天插入几千行的小表，就别折腾了，直接 INSERT 反而更简单。
4.4 NOLOGGING 和 REDO 开销的取舍
普通 INSERT 会写大量 redo 日志，用来保证数据库崩溃恢复。大批量导入时，为了速度，可以给表指定NOLOGGING：
ALTER TABLE emp NOLOGGING; INSERT /*+ APPEND */ INTO emp SELECT ...; ALTER TABLE emp LOGGING;这个操作的本质是：对这些数据的插入不再生成完整 redo 记录。代价是，如果数据库在插入后、备份归档前发生崩溃，这部分数据可能会丢失，而且无法通过 redo 做介质恢复。
我实际的经验是：NOLOGGING 只用在可以重新生成数据的场景，比如临时维度表、每天全量重建的中间表。一旦数据是不可重建的业务核心，别用 NOLOGGING 去赌系统不会崩溃，节省的那点 IO 迟早从别的地方加倍还回来。
4.5 慢插入的常见瓶颈：从等待事件看
如果你发现大批量 INSERT 很慢，先别急着调 SQL。用下面这个查询看看数据库在等什么：
SELECT event, total_waits, time_waited FROM v$system_event WHERE wait_class = 'User I/O' ORDER BY time_waited DESC;常见的瓶颈有三类：
- 日志切换或归档速度跟不上：redo 日志频繁切换，
log file switch (archiving needed)等待。解决方案是加大 redo log 文件大小，或者调整归档频率。 - undo 空间不足：插入大量数据时回滚段不断扩展，
undo segment contention或ORA-30036。看v$undostat可以判断扩展趋势。 - 索引维护竞争：插入列上的索引字段如果顺序性差（比如随机 UUID 做主键），会让索引叶块频繁分裂，
enq: TX - index contention是典型等待。解决方案是用序列做主键，或改成 REVERSE 索引，但这又会牺牲范围扫描性能。
调优的定位思路其实就是：先分清是 CPU 型瓶颈（解析太多）、IO 型瓶颈（redo/数据文件写）还是锁竞争型瓶颈（索引/并行冲突），再针对性地动刀。不要一上来就乱加 HINT，结果把正常的 SQL 给弄出更差的执行计划。
5. INSERT 常见报错的完整排查链路
最后这部分，把我在项目里遇到频率最高的 INSERT 相关报错整理一遍，重点关注排查思路，不是单纯对答案。因为报错信息同样的文本，背后的原因可以完全不同。
5.1 ORA-01400：无法将 NULL 插入
报错原因通常比较直接：某个 NOT NULL 列没有出现在列清单里，或者显式插入了 NULL。但实际定位时往往需要区分两种场景：
一种是在普通 INSERT 语句里，业务给了空值；另一种是在 INSERT SELECT 中，源表某列本身就是 NULL。如果你维护的是几百行 SQL 的数据脚本，看报错还不够快，直接查：
SELECT table_name, column_name, nullable FROM dba_tab_cols WHERE table_name = 'EMP' AND nullable = 'N';把 NOT NULL 列全列出来，同时把这些列和 INSERT 语句中的列对比，基本一两分钟就能找到凶手。
更进阶一点的坑是：某列是 NOT NULL，但你在插入时没写它，同时它也没有默认值。表面看好像列定义了就应该有值，实际上 Oracle 不会帮你猜，只能给你一个 ORA-01400。解决方向是给列加 DEFAULT，或者在 INSERT 前补上合法值。
5.2 ORA-00001 / ORA-02290：唯一约束与 CHECK 约束冲突
唯一约束冲突的报错不多说，业界的标准检查办法是查约束字段、查最大键值、查确实重复的数据。有一个容易被忽略的情况是：Oracle 的唯一约束默认不限制多个 NULL 值。也就是说，如果某列有唯一索引，你可以插入任意多行NULL，不会报冲突。很多人拿唯一约束当作"必填+唯一"双重保障，其实 Oracle 不这么认为。要连 NULL 也锁死，只能用复合唯一索引或者触发器。
CHECK 约束冲突的排查也类似。CHECK 约束常被用来限制取值范围，比如SAL > 0。批量插入时，某条记录的一个值违反 CHECK，整批就回滚了。Oracle 的报错里会给出约束名，但不会告诉你是哪一行、哪个值违规。我写过一个通用的排查脚本：把目标表的数据读取后用 CHECK 约束相同的逻辑过滤一遍，就能揪出所有问题数据。脚本不好写，但思路很朴素——你没法让数据库告诉你哪一行不对，就自己把条件翻译一遍做一次验证查询。
5.3 ORA-01843、ORA-01722、ORA-12899：类型与长度的隐形炸弹
这三个放在一起说，因为它们都和**"值格式/长度"**相关：
ORA-01843 无效的月份：日期字符串解析失败，十有八九是 NLS 设置不统一。ORA-01722 无效数字：字符串转数字失败，比如'12abc'、'12.3'在某种语言设置下解析异常。ORA-12899 值对于列太大：通常拆成两个方向。如果是字符集多字节导致的，把字段长度按字节重新估算或者扩容；如果数据本身就是超出设计长度，说明业务模型和数据流早就失控了，去源头收紧校验才是正解。
排查这类问题，最快的工具是把出错的 SQL 中的值和目标表结构列出来，人工逐列比对。更好的方式是提前做数据质量校验脚本，在正式 INSERT 之前跑一遍，类似：
SELECT COUNT(*) FROM source_tab WHERE LENGTH(ename) > 20 OR LENGTHB(ename) > 60 OR NOT REGEXP_LIKE(sal, '^[0-9]+(\.[0-9]+)?$');这种脚本不复杂，但放在系统上线时的数据迁移类操作中，能帮你避免"执行到中途发现一堆行失败，全部回滚，白白等了半小时"的尴尬。
5.4 ORA-00947 / ORA-00913：列数和值数不匹配
这两个报错都说明 INSERT 语句中列集合与值集合数量对不上。ORA-00947 值不足是值少了，ORA-00913 值过多是值多了。
最常见的原因是：表结构被 ALTER TABLE 加过列，而旧脚本没同步更新。另一种情况在 PL/SQL 里很经典：写动态 SQL 拼接 INSERT 时，绑定变量的数量和数据集合的数量不小心错位了。排查比较简单，逐个数列名和绑定变量，两边对齐即可。
5.5 DML 改成 PL/SQL 后出现的问题
用 PL/SQL 做批量插入时，最常见的报错其实是ORA-06550 PLS-00306（参数数量或类型错误）。这是因为你在 PL/SQL 块里调用了某个过程或打包函数，却忘记传某个参数。这类问题不属于 INSERT 语法本身，但它和 INSERT 经常成对出现——比如动态 SQL 里调用EXECUTE IMMEDIATE拼 INSERT。
经验总结一句话：静态 SQL 能写就不用动态 SQL。动态 SQL 把所有错误推迟到运行时才暴露，而且排查难度成倍上升。如果确实要动态拼 INSERT，一定要绑定变量，而不是把值直接拼进文本里——这既是为了性能，也是为了安全。
我在实际操作中还有一个习惯：在调试 INSERT 时，给每条 SQL 加上注释，标明业务来源。比如：
INSERT INTO order_tail (order_id, item_id, qty) SELECT order_id, item_id, qty FROM staging_tail WHERE batch_id = 20241101; -- 2024年11月1日批次入库看起来很简单，但当你半夜排查数据异常时，这段注释能直接告诉你这是哪条链路进来的数据，少走很多弯路。
还有一个最实用的建表习惯：建表时把必填列做成 NOT NULL，把有默认值的列定义好 DEFAULT，而且给每个字段写上注释。INSERT 的坑，很多其实在建表阶段就已经埋下了。表结构设计得清爽一点，后面写 INSERT 的人就能少踩一半雷。
最后补充一个小技巧：如果你经常写数据脚本，可以把常用的 INSERT 语句模板存在一个 SQL 文件里，每次只改表名和列名。日期格式统一用TO_DATE(..., 'YYYY-MM-DD HH24:MI:SS')，数字统一用数值字面量，字符串里所有单引号都记得翻倍。长期按这个纪律走，INSERT 的报错率会大大下降。
