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 ALLOracle 从 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 (OBrien);这个字符串的实际内容是OBrien。如果有人在 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 一端是 VARCHAR2Oracle 的字符串比较规则会把空格补齐后再比较结果可能出乎意料。更麻烦的是当 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是 NULLreg_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 日志用来保证数据库崩溃恢复。大批量导入时为了速度可以给表指定NOLOGGINGALTER 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 的报错率会大大下降。