sql跨库连接失败需先确认数据库是否支持全限定名：mysql 8.0+和postgresql支持同实例多库全限定名但需权限，sql server需写全schema；oracle dblink需校验链接状态与权限；mysql federated引擎限制多且默认禁用；性能瓶颈常源于网络传输与执行计划未下推。
SQL跨库连接失败，先确认数据库是否支持全限定名
不是所有数据库都允许直接用 database.schema.table 的方式做 JOIN。MySQL 8.0+ 和 PostgreSQL 支持同实例多库的全限定名（如 db2.users），但必须确保当前用户对目标库有 SELECT 权限；SQL Server 也支持 db_name.schema_name.table_name，不过默认 schema 是 dbo，漏写容易报 Invalid object name 错误。
常见踩坑点：
- MySQL 5.7 及更早版本不支持跨库 JOIN 中的子查询引用另一库表（会报
ERROR 1146） - PostgreSQL 要求两库在同一个集群（同一 pg_instance），不能跨 PostgreSQL 实例
- 全限定名中的数据库名、schema 名区分大小写（尤其 PostgreSQL + Linux 环境）
Oracle DBLink 连接远程库：权限和链接状态最关键
DBLink 不是“配好就能用”，每次执行前都会校验远程连接可用性。如果出现 ORA-02068: following severe error from xxx 或 ORA-02049: timeout: distributed transaction waiting for lock，大概率是远端库不可达、账号密码过期，或本地未提交/回滚分布式事务。
实操要点：
- 创建 DBLink 需要
CREATE DATABASE LINK权限，且远程库账号必须显式授权（如GRANT SELECT ON remote_table TO link_user） - 查询时务必带上
@后缀：SELECT * FROM users@my_dblink，漏掉@xxx会被当成本地表 - DBLink 查询无法使用本地索引优化，大表 JOIN 容易触发全表扫描，建议在远程端加好 WHERE 条件下推（如
SELECT * FROM logs@prod_link WHERE dt = '2024-06-01'）
MySQL Federated 引擎替代方案：轻量但限制多
Federated 表本质是本地建一个“指针”，指向远程 MySQL 表，适合只读、低频跨库 JOIN 场景。但它在 MySQL 8.0 默认禁用，启用需在配置文件加 federated 到 plugin_load_add，重启生效。
典型问题：
- 不支持事务一致性：本地 INSERT INTO federated_table 可能成功，但远程失败，无回滚
- 无法使用远程表的 FULLTEXT 或 GENERATED COLUMN
- WHERE 条件不会自动下推到远程，可能拉取整张表再过滤（看
EXPLAIN的rows值是否异常大） - 远程库密码明文写在 CREATE SERVER 语句里，有安全风险
跨数据库 JOIN 的真实瓶颈往往不在语法
即使语法全对、权限全开、网络通畅，JOIN 性能仍可能断崖式下跌——因为数据要在网络间搬运。比如 SELECT a.*, b.name FROM local_orders a JOIN remote_customers@prod_dblink b ON a.cid = b.id，如果 local_orders 有 50 万行，Oracle 会逐条发 ID 去远程查，而不是批量传 IN 列表。
更稳妥的做法：
- 优先考虑 ETL 同步关键字段到本地库（哪怕延迟 5 分钟），避免实时跨库
- 若必须实时，把远程表导出为临时表（如
CREATE GLOBAL TEMPORARY TABLE tmp_cust AS SELECT * FROM cust@link），再与本地表 JOIN - 警惕字符集差异：远程库用
utf8mb4，本地用latin1，JOIN 字段隐式转换会导致索引失效
跨库不是加个点或 @ 就完事，网络延迟、权限链路、字符集、执行计划下推——每个环节都可能让结果对不上或者跑一天不出结果。
