根本原因是字段顺序错位导致列值错配，MySQL按物理列序匹配而非字段名；源表或目标表结构变更（如新增NOT NULL字段、调整列序）会直接引发报错或数据错写，且SELECT *放大IO、权限、大字段等风险。
MySQL 生产环境不建议用 SELECT * 做插入（比如 INSERT INTO t2 SELECT * FROM t1），根本原因不是语法报错，而是它把表结构耦合、字段顺序依赖、类型隐式转换、权限越界等风险全打包塞进一条语句里——一旦源表或目标表结构变更，这条语句大概率直接失败或写入错误数据。
INSERT ... SELECT * 会因字段顺序错位导致列值错配
MySQL 执行 INSERT INTO t2 SELECT * FROM t1 时，完全按物理列序匹配：t1 的第 1 列 → t2 的第 1 列，t1 的第 2 列 → t2 的第 2 列……中间任何一列顺序变动（如 ALTER TABLE t1 MODIFY COLUMN email VARCHAR(255) FIRST），就会让原本该进 user_id 的值写进 email 字段。
- 常见错误现象：
ERROR 1366 (HY000): Incorrect integer value: 'xxx@yyy.com' for column 'user_id' at row 1 - 即使两表字段名相同、类型兼容，只要物理顺序不一致，就必然错配
- 视图或中间件（如 ShardingSphere）对
*的列序解析可能与 MySQL 原生行为不一致，进一步放大错位风险
目标表新增 NOT NULL 字段后，INSERT ... SELECT * 直接报错
若 t2 后续加了 status TINYINT NOT NULL DEFAULT 0，而 t1 没有对应字段，SELECT * 不会自动补默认值，MySQL 会报 ERROR 1136 (21S01): Column count doesn't match value count at row 1 或更隐蔽的 Field 'status' doesn't have a default value。
- ORM 自动生成迁移脚本时，常忽略这种跨表依赖，上线后才发现插入链路中断
- 用
INSERT INTO t2 (a,b,c) SELECT a,b,c FROM t1显式声明列名，就能绕过这个问题 - 哪怕 t2 加的是允许 NULL 的字段，
SELECT *仍会传 NULL 进去——业务上可能要求空字符串或 0，而非 NULL
大字段和权限问题在 INSERT 场景下被放大
SELECT * 在插入时不仅读数据，还强制搬运所有字段内容。如果 t1 包含 log TEXT 或 backup_data LONGBLOB，这些字段会被完整复制到 t2，哪怕 t2 根本不需要它们。
- IO 和网络开销翻倍：一次插入可能触发多次溢出页读取（TEXT/BLOB >728 字节时）
- 权限失控：DBA 给用户只开了
SELECT(id, name)权限，但SELECT *会让插入操作越权读取敏感字段（如password_hash），再写进 t2 —— 这是典型的横向越权 - t2 若没建对应大字段，还会直接报错：
ERROR 1105 (HY000): BLOB/TEXT column used in key specification without a key length
真正麻烦的从来不是多敲几个字段名，而是 SELECT * 让你无法确认“这一行到底要插什么”，也无法在结构变更前预判影响范围。线上表往往被多个服务共享，一个 ALTER TABLE ADD COLUMN 就可能让某条看似稳定的 INSERT ... SELECT * 突然崩掉——而且错误日志里只显示列数不匹配或类型冲突，根本看不出根源在字段顺序或缺失默认值。
