跨库 INSERT INTO SELECT 语法为 INSERT INTO target_db.table_name SELECT ... FROM source_db.table_name，需确保用户对两库有相应权限、字段兼容、目标表预先存在，大表应分批迁移。
跨库 INSERT INTO SELECT 语法怎么写？
直接用 INSERT INTO target_db.table_name SELECT ... FROM source_db.table_name 就行，MySQL 原生支持跨库引用，不需要额外配置或链接。关键在于表名前加数据库名前缀，且执行用户必须对两个库都有对应权限（SELECT 权限在源库，INSERT 权限在目标库）。
常见错误是漏掉库名前缀，比如只写 SELECT * FROM users，结果查的是当前默认库的 users，不是你想迁移的那个库；或者权限没开全，报错 ERROR 1142 (42000): INSERT command denied to user 或 SELECT command denied。
- 源表和目标表字段顺序、类型要兼容，否则会报错或截断（如
VARCHAR(10)插入超长字符串） - 目标表如果有主键/唯一约束，而源数据存在重复值，会中断执行（除非加
IGNORE或改用ON DUPLICATE KEY UPDATE） - 不建议在生产环境直接用
SELECT *，显式列出字段更安全，避免因源表加列导致目标表字段数不匹配
如何处理目标表不存在或结构不一致？
MySQL 不允许 INSERT INTO SELECT 自动建表，目标表必须预先存在。如果只是结构不一致（比如字段少、类型不同），得先手工调整目标表：ALTER TABLE target_db.t ADD COLUMN x INT 或 MODIFY COLUMN y DATETIME。
如果源表字段多于目标表，SELECT 列表里只能写目标表已有的字段名；如果字段少，则需补默认值或 NULL（前提是字段允许 NULL）。
- 用
SHOW CREATE TABLE source_db.t查源表结构，再对比修改目标表，比靠猜靠谱 - 想“复制表结构+数据”，得拆成两步：先
CREATE TABLE target_db.t LIKE source_db.t，再INSERT INTO ... SELECT -
CREATE TABLE target_db.t AS SELECT ... FROM source_db.t虽然能建表，但不会复制索引、主键、AUTO_INCREMENT 等属性，后续还得补ALTER TABLE
大表迁移时卡住或超时怎么办？
默认情况下，整个 INSERT INTO SELECT 是一个事务，数据量大时容易锁表、占满 binlog、触发 max_allowed_packet 或 wait_timeout 超时。不能只靠加大超时参数硬扛。
实际做法是分批迁移：用 WHERE id BETWEEN ? AND ? 或 WHERE id > ? ORDER BY id LIMIT N 控制每次搬几千到几万行。注意别用 OFFSET 分页，大数据量下性能极差。
- 加
ORDER BY和合理索引（比如按主键递增），保证每次取的数据不重不漏 - 每批执行后检查
ROW_COUNT()，确认实际插入行数，避免因 WHERE 条件写错导致漏数据 - 如果目标库是线上库，考虑在低峰期执行，并监控
SHOW PROCESSLIST防止阻塞其他业务查询
为什么用 mysqldump 或 pt-archiver 不总比 INSERT INTO SELECT 好？
因为 INSERT INTO SELECT 是服务端直接搬运，不经过客户端网络传输，速度通常更快、更稳定。mysqldump 导出再导入要走网络+磁盘+解析，pt-archiver 虽支持分批和条件过滤，但本质还是逐行 INSERT，IO 和锁开销更大。
但 INSERT INTO SELECT 的限制也很实在：必须同实例（不能跨 MySQL 实例）、不能改数据逻辑（比如字段拼接、函数转换得在 SELECT 里写死）、无法跳过某些坏行（遇到非法日期等会直接失败）。
- 跨实例迁移？老实用
mysqldump --databases db1 db2 | mysql -h remote或 Flink/CDC 工具 - 需要清洗或转换数据？先在源库建临时视图或中间表，再
INSERT INTO SELECT过去 - 目标表有触发器？确认是否要触发——
INSERT INTO SELECT会触发，而 mysqldump 导入默认不触发
跨库迁移看着简单，真正落地时最常栽在权限、字段映射和批量控制上，而不是语法本身。
