跨厂商数据库无法直接建联合视图，因SQL视图依赖单库引擎，不支持异构查询；必须先将数据同步至同一实例，或通过FEDERATED、postgres_fdw、OPENQUERY等方案间接实现。
跨厂商数据库不能直接建联合视图
SQL 视图本质是一条预存的 SELECT 语句，运行时完全依赖当前数据库引擎的能力。它**不支持直接访问 MySQL + Oracle + PostgreSQL 这类异构数据库**——哪怕你写 SELECT * FROM mysql_db.users UNION ALL SELECT * FROM oracle_db.customers，也会立刻报错，因为解析器根本不知道 oracle_db.customers 是什么。
真正可行的前提只有一个：所有数据必须先被“拉”进同一个数据库实例里，让它们变成本地可查的对象。否则所谓“联合视图”只是语法幻觉。
MySQL 用 FEDERATED 引擎接入同构远程表再建视图
仅适用于 MySQL → MySQL 场景，轻量但脆弱。它不转发 WHERE、JOIN 或 LIMIT，所有计算都在本地做，远程只吐全表数据。
- 确认引擎已启用：
SHOW ENGINES;查看FEDERATED行状态是否为YES - 远程库需开放账号权限，并绑定 IP（如
'user'@'192.168.1.%'） - 本地建表语句字段名、类型、顺序必须和远程表严格一致，否则查询可能静默截断
-
CONNECTION字符串格式固定："mysql://user:pass@host:port/database/table"，端口不能省，密码含@、/等需 URL 编码 - 建好
remote_orders这样的 FEDERATED 表后，才能在视图里写：CREATE VIEW merged_orders AS SELECT * FROM local_orders UNION ALL SELECT * FROM remote_orders
PostgreSQL 用 postgres_fdw 实现带下推的联合视图
比 MySQL 的 FEDERATED 稳定得多，支持谓词下推（WHERE、ORDER BY、简单 GROUP BY 可传到远端执行），但配置步骤多，类型兼容性要求高。
- 先执行：
CREATE EXTENSION postgres_fdw; -
CREATE SERVER定义连接，CREATE USER MAPPING绑定认证凭据 - 推荐用
IMPORT FOREIGN SCHEMA批量导入结构，避免手写CREATE FOREIGN TABLE出错 - 远端字段是
TEXT，本地映射也得声明为TEXT；若用CHAR(20)和TEXT在UNION ALL中会报类型不匹配 - 用
EXPLAIN看执行计划：如果出现Remote SQL: SELECT ...，说明下推成功；否则仍是全量拉取
SQL Server 链接服务器 + OPENQUERY 是跨异构库的务实选择
能连 Oracle、MySQL、PostgreSQL（需装对应 OLE DB/ODBC 驱动），但默认不支持下推，复杂条件会全量拉回。用 OPENQUERY 可强制把查询发到远端执行，绕过本地解析限制。
- 配置链接服务器后，常规四段式引用：
SELECT * FROM [ORACLE_SRVR]..[SCHEMA].[TABLE] - 但
WHERE order_date > '2026-01-01'默认不会下推到 Oracle，而是拉全表再过滤 - 改用：
SELECT * FROM OPENQUERY([ORACLE_SRVR], 'SELECT * FROM orders WHERE order_date > ''2026-01-01''')，此时过滤在远端完成 -
OPENQUERY不支持参数化，拼接 SQL 时注意单引号转义和注入风险 - 视图里嵌套
OPENQUERY是可行的，但每次查询都会建立新连接，高并发下容易耗尽连接数
最常被忽略的一点：跨库链路不是原子通路。视图创建成功 ≠ 查询一定成功。网络抖动、远端库重启、密码过期、防火墙策略变更，都可能导致查询返回空或超时——而这些错误往往不报具体原因，只静默失败。上线前务必用 SELECT 直接测试每一张远程表的可访问性，别等视图跑起来才排查。
