原生 INSERT 不支持跨服务器，因 SQL 标准未定义服务器通信机制且解析器无法路由远程实例；可行方案仅两种：数据库内置外部表（如 PostgreSQL 的 postgres_fdw、MySQL 的 FEDERATED）或应用层/工具搬运数据。
不能直接用标准 SQL 的 INSERT INTO ... SELECT 跨不同数据库服务器执行，除非目标数据库明确支持并已配置好外部数据源能力（如 PostgreSQL 的 postgres_fdw、SQL Server 的链接服务器、MySQL 8.0+ 的 FEDERATED 引擎等）。
为什么原生 INSERT 不支持跨服务器
SQL 标准本身不定义服务器间通信机制，INSERT 是本地执行语句，解析器无法自动路由到远程实例。常见错误如 ERROR 1146 (42S02): Table 'remote_db.table_name' doesn't exist 或连接超时，本质是客户端把远程库名当成本地库处理了。
真正可行的路径只有两条：一是借助数据库内置的「外部表」或「联邦查询」功能；二是由应用层或中间工具承担数据搬运职责。
PostgreSQL 使用 postgres_fdw 实现远程 INSERT
这是目前最稳定、权限控制最细的方案，但需在目标库（被写入方）和源库（发起方）都做配置：
- 目标库必须开启
shared_preload_libraries = 'postgres_fdw'并重启 - 源库执行
CREATE EXTENSION IF NOT EXISTS postgres_fdw - 用
CREATE SERVER定义远程连接，CREATE USER MAPPING绑定凭据 - 用
CREATE FOREIGN TABLE映射远程表结构（字段类型、NOT NULL 约束必须严格一致） - 之后才能对这个
FOREIGN TABLE执行INSERT，它会透传到远端执行
注意：postgres_fdw 默认不支持 INSERT ... RETURNING，且批量插入性能受网络延迟影响明显，建议用 COPY 替代多行 INSERT。
MySQL 8.0+ 启用 FEDERATED 引擎写远程表
MySQL 原生支持较弱，FEDERATED 引擎仅适用于简单场景：
- 启动时必须加参数
--federated（5.7 默认禁用，8.0 默认关闭） - 建表语句中
CONNECTION字符串需包含完整远程地址、库、表、用户密码（明文风险！） - 远程表结构必须与本地
FEDERATED表完全一致，否则INSERT会静默失败或截断数据 - 不支持事务跨引擎传播，远程写入失败时本地事务无法回滚
示例建表语句：CREATE TABLE remote_users (id INT, name VARCHAR(50)) ENGINE=FEDERATED CONNECTION='mysql://user:pass@192.168.1.100:3306/testdb/users';
绕过数据库限制：用 mysqldump + mysql 客户端管道
当无法修改目标库配置时，最通用的做法是「导出→传输→导入」三步走：
- 在源库机器运行：
mysqldump --host=src_host --user=u1 --password=p1 --no-create-info --skip-extended-insert db1 table1 | mysql --host=dst_host --user=u2 --password=p2 db2 -
--skip-extended-insert避免单条语句过长触发max_allowed_packet错误 - 若网络不稳定，改用
gzip压缩管道：mysqldump ... | gzip | ssh dst_host "gunzip | mysql ..." - 注意字符集一致性，显式加上
--default-character-set=utf8mb4防止乱码
这种方案看似笨重，但胜在不依赖目标库扩展能力，也规避了 FDW 类功能常见的权限穿透和锁等待问题。
跨服务器写入真正的难点不在语法，而在权限链路是否闭合：从网络连通、账号授权、字符集对齐，到事务语义能否传递。多数线上环境最终选择应用层双写或消息队列异步同步，就是因为数据库层的「透明远程写入」本质上是在用复杂性换便利性。
