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