<p>MySQL跨库JOIN需同实例且用户对两库均有SELECT权限，语法为db_name.table_name；权限不足会报ERROR 1142，须显式授权如GRANT SELECT ON db_a.* TO 'user'@'%';。</p>
MySQL 中跨库 JOIN 的写法和权限前提
MySQL 支持直接跨数据库 JOIN，但前提是两个库在同一实例、且当前用户对两个库都有 SELECT 权限。语法上只需在表名前加上库名前缀：database_name.table_name。
常见错误是执行时提示 ERROR 1142 (42000): SELECT command denied to user —— 这不是语法问题，而是权限缺失。DBA 需显式授权，例如：
GRANT SELECT ON `db_a`.* TO 'user'@'%'; GRANT SELECT ON `db_b`.* TO 'user'@'%';
注意：不能只授 SELECT ON *.*（除非是 root），MySQL 8.0+ 默认禁止通配符跨库授权。
PostgreSQL 不支持原生跨库 JOIN
PostgreSQL 的数据库（database）是相互隔离的进程级概念，JOIN 无法直接引用其他 database 的表。强行写 other_db.public.users 会报错：cross-database references are not implemented。
可行方案只有两个：
- 用
postgres_fdw扩展创建外部表（foreign table），再 JOIN —— 需要 DBA 启用扩展、建 server、user mapping，并且目标库开启password_encryption = scram-sha-256（若用密码认证） - 应用层分两次查，用内存合并（适合小数据量）
别试图用 dblink 拼 SQL 字符串再 JOIN —— 它返回的是记录集，无法直接参与 JOIN 条件推导，性能差且难维护。
SQL Server 跨库 JOIN 要注意默认架构和四部分命名
SQL Server 允许跨库 JOIN，但必须用四部分命名：[database].[schema].[table]。漏掉 [schema]（通常是 dbo）会导致 Invalid object name 错误。
典型写法：
SELECT u.name, o.order_date FROM db_user.dbo.users u JOIN db_order.dbo.orders o ON u.id = o.user_id;
容易踩的坑：
- 目标库未设为
TRUSTWORTHY ON（仅当用到 CLR 或非 sa 用户调用跨库对象时才需要，多数场景不用） - 登录用户在目标库没对应
USER，导致权限继承失败 —— 应在每个库中运行CREATE USER ... FOR LOGIN - 数据库处于
READ_ONLY状态时，仍可 SELECT，但若 JOIN 中含临时表或 CTE，可能触发隐式写操作而失败
跨库 JOIN 的性能和事务边界风险
跨库 JOIN 本质是单实例内的逻辑操作，不涉及网络传输（除 PostgreSQL 的 postgres_fdw 外），但优化器可能无法准确估算远端表统计信息，导致执行计划劣化。
更关键的是事务语义：MySQL 和 SQL Server 中，跨库操作仍在同一事务内，ROLLBACK 可回滚全部；但 PostgreSQL 的 postgres_fdw 外部表默认是 AUTOCOMMIT 行为，无法参与本地事务 —— 即使你套了 BEGIN，远端修改也不会回滚。
线上高并发场景下，跨库 JOIN 还容易成为单点瓶颈，尤其当被 JOIN 的库负载已高时 —— 它不会自动降级或熔断，只会拖慢整个查询。
