跨节点批量迁移不能用单条insert into...select，因分库分表后源目标不在同一实例，主流数据库不支持跨实例select，会报“table doesn't exist”或“cross-database reference not supported”错误。

跨节点批量迁移数据不能靠单条 INSERT ... SELECT 直接搞定，因为分库分表后源和目标通常不在同一数据库实例，甚至不在同一物理节点。

为什么标准 INSERT INTO ... SELECT 会失败

MySQL、PostgreSQL 等主流数据库不支持在 SELECT 子句中直接引用其他实例的表（除非配置了联邦引擎，如 MySQL 的 FEDERATED 或 PostgreSQL 的 postgres_fdw，但生产环境极少启用）。执行类似 INSERT INTO db2.t_user SELECT * FROM db1.t_user 时，数据库会报错：Table 'db1.t_user' doesn't exist 或 cross-database reference not supported。

常见错误现象：

• 客户端报错：「Unknown database 'db1'」或「No route to host」
• 即使库名能解析，也会因权限隔离或网络策略被拒绝
• 使用逻辑备份工具（如 mysqldump）导出再导入，无法保证分片键路由一致性

推荐做法：用应用层或中间件驱动的批量拉取 + 写入

真正可控、可监控、可重试的方式是把迁移逻辑从 SQL 层上移到应用或脚本层。核心思路是「查出来 → 按目标分片规则计算路由 → 发送到对应节点写入」。

实操建议：

• 用 Python/Java 编写迁移脚本，连接源库执行 SELECT（带 LIMIT 和 OFFSET 或基于自增主键分段），每次拉取 1000–5000 行
• 对每行数据调用分片算法（例如 user_id % 4 决定写入 shard_0～shard_3），生成目标库连接和 INSERT 语句
• 使用批量插入（如 MySQL 的 INSERT INTO t VALUES (...), (...), (...)）降低网络往返开销
• 务必关闭自动提交，每批执行后显式 COMMIT，失败时 ROLLBACK 并记录 error_log
• 避免在事务中跨多个目标节点写入——这会引入分布式事务复杂度，应确保单批只写一个分片节点

如果必须用纯 SQL：借助中间节点做代理（仅限特定场景）

某些分库分表中间件（如 ShardingSphere-Proxy、MyCat）支持“跨数据源查询”，但仅限于 SELECT；写入仍需走路由。真正能用 SQL 完成迁移的例外情况只有：

• 源库和目标库在同一 MySQL 实例下，且用不同 schema（如 db_old.user → db_new.user），此时可用 INSERT INTO db_new.user SELECT * FROM db_old.user WHERE id BETWEEN ? AND ?
• 使用 MySQL 8.0+ 的 DATA DIRECTORY 或表空间迁移，但这不是“跨节点”，只是文件级挪动
• 通过 mysqlpump 或 mydumper 导出带 --skip-triggers --skip-views 的纯数据 SQL，再用 sed 替换库名和表名后导入目标节点——但需手动校验分片键分布是否符合预期

最容易被忽略的三个点

迁移不是“把数据倒过去”就完事：

• auto_increment 值在目标表必须重新规划，否则后续插入可能冲突；建议迁移后执行 ALTER TABLE t_user AUTO_INCREMENT = ? 调整起始值
• 时间字段（如 created_at）若依赖数据库默认值（CURRENT_TIMESTAMP），迁移时要显式写出值，否则会被重置为导入时刻
• 外键、触发器、全文索引等对象不会随数据迁移，必须提前在目标分片上建好，且注意各节点 DDL 是否完全一致