INSERT INTO SELECT 易错点包括：字段数量/类型不匹配、NOT NULL字段未处理NULL、字符集不一致致乱码、自增主键冲突、大数据量锁表超时、跨库权限与路径缺失。
INSERT INTO SELECT 语法写错就全表乱插
直接用 INSERT INTO SELECT 导数据，最常踩的坑是字段数量或类型不匹配，MySQL 会报错 Column count doesn't match value count 或静默截断/转换失败。这不是语法问题，而是你没对齐源表和目标表的列结构。
- 必须显式写出目标列名，别偷懒写
INSERT INTO t2 SELECT * FROM t1—— 除非两张表字段顺序、数量、类型完全一致（现实中几乎不存在） - SELECT 的字段顺序要和 INSERT 后面的列顺序严格对应，不是按名字匹配
- 遇到
NOT NULL字段但源数据为NULL，会报错Column 'xxx' cannot be null，得提前用COALESCE()或IFNULL()处理 - 字符集或排序规则不一致时，可能触发隐式转换警告，甚至插入乱码，查
SHOW WARNINGS能看到
目标表有自增主键，怎么避免冲突
如果目标表有 id 自增主键，而你又想从源表带值导入（比如迁移历史数据），直接 SELECT 带 id 字段会导致主键冲突或跳号。关键不是关掉自增，而是控制要不要让 MySQL 插入时接管这个字段。
- 想保留源表
id值？在 INSERT 列表里明确写出id，例如：INSERT INTO t2 (id, name, created_at) SELECT id, name, created_at FROM t1 - 想让 MySQL 自动分配新
id？INSERT 列表里**不要写**id，同时确保 SELECT 对应位置也不提供值（可写NULL或留空，但推荐省略） - 若目标表
id是PRIMARY KEY AUTO_INCREMENT，且你传了非NULL值，MySQL 会直接用你给的值 —— 这没问题，但后续自增值会基于你插入的最大值更新，容易引发意外跳号
大数据量下卡死或超时怎么办
INSERT INTO SELECT 是单条语句，MySQL 会锁住目标表（至少是行锁或表锁，取决于引擎和隔离级别），数据一多就卡住其他写操作，还可能触发 max_allowed_packet 或 wait_timeout 错误。
- 先查源表大小：
SELECT COUNT(*) FROM t1，超过 10 万行建议分批，别一把梭 - 用
LIMIT+OFFSET分页风险高（并发下可能漏/重），更稳的是按主键范围切分，例如：SELECT * FROM t1 WHERE id BETWEEN 10000 AND 20000 - 临时调大参数（仅会话级）：
SET SESSION sort_buffer_size = 4*1024*1024;，但别动innodb_log_file_size这类需重启的配置 - 确认存储引擎：MyISAM 表在 INSERT 过程中会锁整张表；InnoDB 虽支持行级锁，但大批量仍可能升级为间隙锁，影响并发
跨库导入时路径和权限容易被忽略
很多人以为只要连上 MySQL 就能跨库 SELECT，其实库名、用户权限、甚至 SQL 模式都可能拦住你。
- 跨库必须写全限定名：
INSERT INTO db2.t2 (...) SELECT ... FROM db1.t1，不能只写表名 - 执行用户必须同时拥有
db1.t1的SELECT权限 和db2.t2的INSERT权限，缺一不可 - 如果目标库开启了
sql_mode=STRICT_TRANS_TABLES，而源数据有空字符串插进NOT NULL VARCHAR字段，会直接报错；可临时改模式：SET SESSION sql_mode = ''（仅限测试环境） - 注意时区：若字段含
DATETIME，且两库所在服务器时区不同，NOW()类函数行为会不一致，但SELECT已存时间值不受影响
事情说清了就结束
