报错“Column count doesn't match value count at row 1”指INSERT字段列表与VALUES值数量不一致，MySQL执行前硬校验；常见原因包括误含生成列、自增主键未留位、显式列出但未赋值的默认值字段等。
字段数不匹配的报错到底在说啥
报错 Column count doesn't match value count at row 1 不是语法错误，而是 MySQL 在执行前做的硬校验：你写的 INSERT INTO t (a, b, c) 声明了 3 列，那后面 VALUES 每一组就必须刚好塞 3 个值。少一个、多一个、批量里某一行少一个——全崩。
为什么明明写了3个字段，还是报错？查隐藏列
常见但容易被忽略的“隐形字段”包括：
- 生成列（
GENERATED ALWAYS AS）：它不参与 INSERT，但如果你用SELECT *反推字段列表，会误把它当普通列加进去 - 自增主键（
id INT AUTO_INCREMENT PRIMARY KEY）：如果没显式写进字段列表，又没在VALUES里留空位，MySQL 不会自动跳过——它只认你列出的字段和对应值 - TIMESTAMP 或 DATETIME 的
CURRENT_TIMESTAMP默认值：这类字段虽有默认值，但若你在字段列表里写了它，就必须给值或显式写DEFAULT - 触发器或分区表约束：某些分区策略会隐式要求插入时带分区键，否则报的还是这个错，但根源不在字段数本身
最稳的办法是执行 SHOW CREATE TABLE t;，逐行对照输出里的 COLUMN 定义，而不是依赖 IDE 提示或记忆。
默认值不是免死金牌，尤其在严格模式下
即使字段定义了 DEFAULT 'unknown' 或 NOT NULL DEFAULT 0，只要你显式列出了该字段，MySQL 就要求你给值（或写 DEFAULT）。漏掉 ≠ 自动填充。
-
INSERT INTO user (name, status) VALUES ('alice');→ 报错，因为status被列出但没给值 -
INSERT INTO user (name, status) VALUES ('alice', DEFAULT);→ 合法，显式调用默认逻辑 -
INSERT INTO user (name) VALUES ('alice');→ 合法，status没出现，走默认值
顺手检查当前模式：SELECT @@sql_mode;。如果含 STRICT_TRANS_TABLES，连隐式转换都会炸；没有的话可能静默截断，反而更难定位问题。
ORM 和批量插入时最容易翻车的点
框架生成 SQL 时，常因模型字段与 DB 表不同步导致列数错位，比如 Java 实体类新加了 tenant_id 字段但没同步建表，或 MyBatis 的 <insert> 标签里漏写了新字段。
- 批量插入多行时，每组
VALUES必须列数一致：VALUES (1,2), (3,4,5)是非法的，哪怕只有最后一行多一个 - 用预处理语句（
INSERT INTO t (a,b) VALUES (?,?)）能提前暴露参数个数不对，比拼字符串安全得多 - 从 CSV 或其他表
INSERT ... SELECT时，务必显式写字段：INSERT INTO t1 (x,y) SELECT a,b FROM t2，别用SELECT *
真正麻烦的是字段数“看似匹配，实则错位”：比如源表加了生成列，SELECT * 返回 5 列，但目标表只有 4 个可写列——这时候报错位置和实际原因隔得很远，得盯住 SHOW CREATE TABLE 输出和执行计划里的投影列。
