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 逐字核对起，别假设“应该没错”。