分库分表后INSERT INTO ... SELECT跨实例必然失败，因数据库引擎不支持跨TCP连接查表；唯一可行例外是源表与目标表同属同一MySQL实例；真正可用方式是应用层分批拉取+分片路由写入。
分库分表后，不能直接用 INSERT INTO ... SELECT 跨实例迁移数据——这不是语法问题，而是数据库架构层面的硬限制。
为什么 INSERT INTO ... SELECT 在分库分表下必然失败
主流数据库（MySQL、PostgreSQL）默认禁止在 SELECT 子句中引用其他实例的表。哪怕你写 INSERT INTO shard2.users SELECT * FROM shard1.users，也会立刻报错：
-
Table 'shard1.users' doesn't exist（库名根本无法解析） -
cross-database reference not supported（跨库引用被拒绝） -
Unknown database 'shard1'或No route to host（网络或权限拦截）
根本原因不是权限没开、也不是SQL写错了，而是数据库引擎压根不设计“跨TCP连接查表”这回事。FEDERATED、postgres_fdw 等联邦方案生产环境极少启用，且性能/稳定性风险高，不应作为迁移主路径。
真正可用的迁移方式：应用层拉取 + 分片路由写入
必须把“查→算→写”三步从 SQL 层移到代码里。关键不是“能不能写一条SQL搞定”，而是“谁来承担路由逻辑和错误恢复”。
- 用
SELECT ... LIMIT 5000 OFFSET 0或基于自增主键分段（如WHERE id BETWEEN 100000 AND 199999）从源库分批读取 - 对每行调用你的分片算法（例如
user_id % 4→ 决定写入shard_0～shard_3） - 按目标分片动态获取对应
*sql.DB连接，拼INSERT INTO users VALUES (?, ?, ?)批量执行（推荐一次 100–500 行） - 每批显式
tx.Commit()；失败则tx.Rollback()并记录error_log，支持断点续传 - 严禁单个事务跨多个目标节点写入——这等于引入分布式事务，会极大增加复杂度与失败概率
纯 SQL 场景下唯一可行的例外
只有当源表和目标表物理上共存于**同一 MySQL 实例**（哪怕不同 schema），才能安全使用 INSERT INTO ... SELECT：
INSERT INTO new_schema.users (id, name, email) SELECT id, name, email FROM old_schema.users WHERE id BETWEEN 100000 AND 199999;
这种场景本质是“单机多库”，不涉及网络路由，也不触发跨实例校验。但注意：
- 必须确认两个 schema 确实在同一个
mysqld进程下（查SHOW VARIABLES LIKE 'port';和SELECT @@hostname;） - 若目标表已存在分片逻辑（比如实际是
users_0,users_1），这条语句只会写入一个物理表，不会自动路由——仍需应用层或中间件介入 -
mysqldump、mydumper等工具导出再导入，无法保证分片键一致性，仅适合做初始快照，不能替代路由写入
最容易被忽略的一点：分片算法必须和线上服务完全一致。哪怕哈希函数少一个 % 或时间分片边界差 1 秒，迁移进去的数据就永远找不到——查不到、删不掉、同步不了。迁移脚本里那几行路由计算，得跟业务代码里 copy-paste 同一份逻辑，而不是手写一遍。
