最常用写法是insert into target_table select...from source_table，需确保字段数量、顺序、类型兼容；显式指定目标列名、避免select *、注意not null约束、数值类型转换、主键冲突处理（如insert ignore或on duplicate key update）、分批插入防oom、字符集与时区对齐。
INSERT INTO SELECT 语法怎么写才不报错
直接用 INSERT INTO target_table SELECT ... FROM source_table 是最常用方式，但必须保证字段数量、顺序、类型基本兼容。MySQL 不会自动转换类型或补默认值，字段数对不上就立刻报 Column count doesn't match value count。
实操建议：
- 显式写出目标列名，别偷懒用
INSERT INTO t1 SELECT * FROM t2—— 表结构稍有变动就挂 - SELECT 的字段顺序要和 INSERT 指定的列顺序严格一致，不是按名字匹配
- 如果目标表有
NOT NULL字段且没在 SELECT 中提供值，又没设默认值，会报Field 'xxx' doesn't have a default value - 数值型字段插入字符串（如
'abc'）可能被转成0或报错，取决于 SQL mode（比如开启STRICT_TRANS_TABLES就直接拒绝）
目标表有主键或唯一索引时怎么避免重复插入
原生 INSERT INTO ... SELECT 遇到主键/唯一冲突就直接报错退出，不会跳过。想忽略冲突继续插，得加控制逻辑。
实操建议：
- 用
INSERT IGNORE INTO ... SELECT：冲突行静默跳过，其余正常插入；注意它也会忽略其他错误（如类型转换失败），不够精准 - 用
INSERT INTO ... SELECT ... ON DUPLICATE KEY UPDATE id=id（空更新）：只跳过冲突，不掩盖其他错误；如果想更新某些字段，把id=id换成col=VALUES(col) - 别依赖
REPLACE INTO：它本质是 DELETE + INSERT，会触发删除动作（影响外键、自增 ID、触发器），多数场景不合适
大表导数据卡住或 OOM 怎么办
一次性 SELECT 几百万行再 INSERT，容易拖慢源表查询、撑爆连接内存、锁表太久。MySQL 默认事务里执行整个语句，没分批概念。
实操建议：
- 加
LIMIT和OFFSET分页导（需配合 ORDER BY 确保确定性），例如每次取 1 万条：INSERT INTO t2 SELECT * FROM t1 WHERE id > ? ORDER BY id LIMIT 10000 - 用主键/时间戳做游标比 OFFSET 更高效，避免深分页扫描
- 确认
max_allowed_packet足够大，否则大结果集直接截断报Packets larger than max_allowed_packet are not allowed - 临时关掉 autocommit 并手动 COMMIT，减少日志刷盘压力；但别让事务过大，否则 binlog 和 undo log 膨胀
字符集和时区不一致导致乱码或时间偏移
源表和目标表字符集不同（比如源是 utf8mb4，目标是 latin1），或者连接层字符集没对齐，SELECT 出来的字符串一插进去就变问号或乱码。时间字段同理，TIMESTAMP 会按连接时区转换，DATETIME 则不会。
实操建议：
- 查清两边表的字符集：
SHOW CREATE TABLE t1和SHOW CREATE TABLE t2，确保列级CHARSET和COLLATE兼容 - 执行前先设连接字符集：
SET NAMES utf8mb4（推荐），比在 URL 里传参数更可控 - 时间字段用
DATETIME类型迁移最稳；如果非用TIMESTAMP，确保 session 的time_zone一致，或显式转成 UTC：CONVERT_TZ(created_at, '+08:00', '+00:00')
最容易被忽略的是字段隐式转换和 SQL mode 的实际影响——同一句 INSERT INTO ... SELECT 在开发机和生产库行为可能完全不同，因为 mode 开关不一样。上线前务必在目标环境跑一遍真实数据验证。
