error 1136 最常见原因是 insert 语句中列数与 values 值数量不一致,包括漏字段、多赋值、select 列数不匹配等;也见于 insert set 漏必填列、load data 字段分隔错误或触发器/生成列干扰。

INSERT VALUES 列数和值数量不一致
这是 ERROR 1136 最常见的触发场景:插入语句中指定的字段个数与 VALUES 提供的值个数对不上。MySQL 会严格校验二者是否相等,哪怕只差一个,就直接报错。
常见错误现象包括:
- 漏写某个字段(比如表有 5 列,
INSERT INTO t(a,b,c,d,e) VALUES (1,2,3)) - 多写了值(比如
INSERT INTO t(a,b) VALUES (1,2,3)) - 用了
*却没匹配全列(INSERT INTO t SELECT *但源查询列数 ≠ 目标表列数)
实操建议:
- 用
DESCRIBE table_name或SHOW COLUMNS FROM table_name确认目标表实际列数和顺序 - 显式写出所有字段名,避免依赖隐式顺序;尤其当表结构后续可能变更时
- 若用
SELECT插入,确保SELECT的字段个数、类型、顺序与目标表兼容,必要时用NULL或默认值占位
INSERT SET 语法中漏掉字段或重复赋值
INSERT ... SET 是 MySQL 特有语法,看起来更直观,但同样受列数约束——它本质是把每个 key=value 当作一列赋值,最终仍要覆盖所有非空非默认的必填列(如 NOT NULL 且无 DEFAULT 的列)。
容易踩的坑:
- 误以为
SET a=1就够了,但表还有b和c是NOT NULL,没提供值 → 报 1136(严格模式下)或 1364(缺失默认值) - 同一个字段在
SET中出现两次,如SET id=1, id=2,部分版本会静默取后者,但某些配置下也可能触发解析异常
实操建议:
- 优先用标准
INSERT INTO ... (col1,col2) VALUES (...)写法,语义清晰、兼容性好 - 如果坚持用
SET,务必检查表结构中哪些列不允许为NULL且无默认值,全部显式赋值 - 注意 MySQL 模式:开启
STRICT_TRANS_TABLES时,缺失必填字段会直接报 1136;关闭时可能插进去空值,掩盖问题
使用 LOAD DATA INFILE 时字段分隔不匹配
当用 LOAD DATA INFILE 导入 CSV/TXT 文件时,1136 常表现为“文件里每行字段数 ≠ 表定义列数”。这不是 SQL 语法错误,而是数据层面的列对齐失败。
典型原因:
- CSV 中某行多了逗号(比如文本含未转义的
,),导致解析出多一列 - 字段包裹符(如双引号)不闭合,让 MySQL 跨行合并解析
- 指定了
FIELDS TERMINATED BY '\t',但文件实际用空格或逗号分隔 -
IGNORE N LINES没跳过表头,而表头被当成数据行读入
实操建议:
- 先用
head -n 5 your_file.csv查看原始文件真实分隔方式和首几行结构 - 在
LOAD DATA语句中明确指定FIELDS TERMINATED BY、ENCLOSED BY、LINES TERMINATED BY - 加
IGNORE 1 LINES跳过标题行(如果存在) - 导入前用
CREATE TABLE ... SELECT或临时表验证解析结果,比直接灌生产表更安全
触发器或生成列间接导致列数不匹配
有时候明明 INSERT 语句本身字段和值数量一致,却仍报 1136。这往往是因为表上有 BEFORE INSERT 触发器修改了新行内容,或存在生成列(GENERATED ALWAYS AS)影响了列计数逻辑。
特别要注意:
- 触发器里对
NEW.col赋了值,但该列原本是NOT NULL DEFAULT CURRENT_TIMESTAMP,触发器又没处理其他必填列 → 实际插入时缺列 - 生成列被定义为
STORED且参与主键/索引,但表达式引用了不存在的字段,导致元数据校验失败 - MySQL 8.0+ 对虚拟生成列 + 外键组合有额外约束,某些插入路径会提前拒绝
实操建议:
- 查触发器:
SELECT * FROM information_schema.TRIGGERS WHERE EVENT_OBJECT_TABLE = 'your_table'; - 查生成列:
SELECT COLUMN_NAME, GENERATION_EXPRESSION FROM information_schema.COLUMNS WHERE TABLE_NAME = 'your_table' AND EXTRA LIKE '%generated%'; - 临时禁用触发器测试(
SET @TRIGGER_CHECKS = FALSE;,仅限调试,勿在线上长期使用)
1136 表面是数字不匹配,背后可能是结构、数据、配置、甚至权限链路的隐性耦合。最稳妥的方式,永远是从 DESCRIBE 和原始 SQL 逐字核对起,别假设“应该没错”。










