mysql 8.0+ 的 federated 引擎支持跨实例查询，但需远程启用插件、结构严格一致、凭据明文风险高，且聚合无法下推；postgresql 的 postgres_fdw 支持 where/join/聚合下推，性能更优；clickhouse 的 remote 引擎天然支持分片并行与聚合下推，适合 olap；三者均需注意权限、网络、时区一致性。
MySQL 8.0+ 使用 FEDERATED 引擎连接远程表
MySQL 原生支持跨实例查询，但仅限于 FEDERATED 存储引擎，且要求目标表结构完全一致、远程库开启 federated 插件并授权访问。它不支持跨库 JOIN 的自动下推优化，所有数据会拉到本地再聚合，容易 OOM 或超时。
实操要点：
- 确认远程 MySQL 已启用
federated：运行SHOW ENGINES;查看状态；若为DISABLED，需在配置文件加federated并重启 - 本地建表语法必须与远程表字段名、类型、长度、字符集严格一致，否则查询报错
ERROR 1429 (HY000): Unable to connect to foreign data source - 连接字符串中密码明文写入，生产环境建议用 MySQL 8.0+ 的
CREATE SERVER+CREATE USER MAPPING隔离凭据 - 聚合函数（如
SUM()、COUNT()）无法下推，SELECT COUNT(*) FROM federated_table会全量拉取再计数
PostgreSQL 通过 postgres_fdw 实现联邦查询
postgres_fdw 是 PostgreSQL 官方推荐的跨实例方案，支持下推 WHERE、JOIN、聚合（部分场景），性能远优于 MySQL 的 FEDERATED。
关键步骤：
- 先在本地库执行
CREATE EXTENSION postgres_fdw;，再用CREATE SERVER定义远程连接，注意host、port、dbname必须准确 -
CREATE USER MAPPING绑定远程账号，避免在CREATE FOREIGN TABLE中硬编码密码 - 定义
FOREIGN TABLE时，列名和类型必须匹配远程表，但可省略无关列；若远程表有索引，本地查询带条件时可能触发下推 - 跨库聚合如
SELECT SUM(sales) FROM local_orders JOIN remote_customers USING (cid)，只要 JOIN 条件和聚合字段能下推，就比拉取全量高效得多
ClickHouse 联合多实例查：用 Remote 表引擎或 Table Function
ClickHouse 对跨实例聚合最友好，remote 表引擎和 remote() 表函数都支持分片并行查询与聚合下推，适合 OLAP 场景。
典型用法：
- 用
remote('shard1:9000|shard2:9000', 'db', 'table')直接查多个节点，WHERE 和 GROUP BY 默认下推，结果在 coordinator 节点合并 - 若需跨不同集群（非分片），改用
cluster表函数配合已定义的remote_servers配置，避免硬编码地址 - 注意
remote不支持事务，且远程节点版本差异可能导致函数不可用（如新版quantileExact()在旧版报错Unknown function） - 聚合字段类型要一致，比如一个实例用
UInt64，另一个用Int64，SUM()会失败并提示Type mismatch
通用陷阱：权限、网络与数据一致性
无论哪种方案，实际落地时最常卡在三件事上：远程库没开对应 IP 白名单、目标用户缺 SELECT 权限、时间戳字段因时区未同步导致聚合错乱。
排查顺序建议：
- 先用
telnet remote_host 3306（MySQL）或nc -zv remote_host 5432（PostgreSQL）确认端口通；防火墙和云厂商安全组常被忽略 - 远程库执行
SHOW GRANTS FOR 'user'@'%';，确保包含目标库表的SELECT，MySQL 还需GRANT FILE（FEDERATED 内部依赖） - 涉及时间聚合时，统一用 UTC 存储，并在查询中显式转换：
toStartOfHour(toTimeZone(event_time, 'UTC'))，避免夏令时跳变引发漏统计
跨实例聚合不是“写个 SQL 就完事”，每个环节的隐式约束都可能让查询静默失败或结果偏差——尤其当远程表结构悄悄变更、或某节点临时不可达时，错误未必立刻暴露。
