column count doesn't match 错误主因有四：①insert未显式指定列名且values个数≠表列数；②insert...select子查询列数≠目标列数；③union各分支列数不等；④mysqldump恢复时表结构已变更。
SELECT字段数和INSERT目标列数不一致
这是最常见触发 Column count doesn't match 的场景：INSERT语句里没显式写目标列，但VALUES里的表达式个数和表实际列数对不上。MySQL不会自动跳过默认值或自增列——它只机械比对「你写了几个值」和「这张表有多少列」。
- 显式写出目标列名，比如
INSERT INTO users (name, email) VALUES ('Alice', 'a@b.c')，而不是INSERT INTO users VALUES (...) - 如果真要用无列名写法，必须严格按
DESCRIBE table_name返回的列顺序、列数提供值，包括NULL占位（哪怕该列允许NULL） - 注意隐藏列：TIMESTAMP有默认值、AUTO_INCREMENT列不参与计数，但它们仍算作“表的一列”，影响总数
子查询返回列数与外层期望不匹配
在 INSERT ... SELECT 或 WHERE ... IN (SELECT ...) 中，子查询多选了一列、少选了一列，或者用了 * 但目标表结构已变，都会立刻报这个错。
-
INSERT INTO log (msg, level) SELECT message, severity FROM raw_events—— 必须确保SELECT返回恰好两列，且顺序对应 - 避免在子查询里用
*，尤其当表结构可能被ALTER过；换成明确列名更安全 - 如果子查询带JOIN，检查是否意外引入了重复列名（如两个表都有
id），用别名限定可避免歧义，但列数仍要手动核对
UNION前后SELECT的列数或类型隐式冲突
UNION要求每个分支的SELECT返回相同数量的列，且对应位置的类型尽量兼容。列数不等会直接报 Column count doesn't match，而类型差异有时会延迟到执行时报错或静默转换。
- 每个 UNION 分支都必须有相同数量的
SELECT表达式，SELECT 1, 'a' UNION SELECT 2是非法的 - 用
SELECT NULL AS col1, NULL AS col2补齐缺失列，比硬凑值更清晰 - 不要依赖MySQL的隐式类型转换来“对齐”列，比如
SELECT 1 UNION SELECT '1'虽然能过，但后续加WHERE可能出问题
用mysqldump恢复时表结构已变更
dump文件里INSERT语句是按当时表结构生成的。如果先dump再ALTER TABLE删/增列，再导入，就会因行数据列数和当前表定义不符而失败。
- 恢复前先用
SHOW CREATE TABLE确认目标表结构，和dump头里的CREATE TABLE语句对比 - 如果只是多了自增或默认值列，可在导入前临时
SET SQL_MODE='NO_AUTO_VALUE_ON_ZERO'，但治标不治本 - 更稳妥的做法：用
mysqldump --skip-inserts先导结构，再人工调整后再导数据；或用--compatible=ansi减少方言依赖
真正麻烦的不是语法错，而是错误发生在批量脚本或CI流程里——日志只打印一句报错，得倒回去逐条查INSERT语句对应的表结构快照。建议把表结构校验做成部署前置检查项，而不是等INSERT执行时才暴露。
