视图无法跨数据库实例或厂商直接整合数据，必须先将多源数据统一接入同一数据库实例：MySQL用FEDERATED（仅同构）、PostgreSQL用postgres_fdw（支持下推）、SQL Server用Linked Server（需OPENQUERY优化），但真正跨厂商应通过ETL落地数仓再建视图。
视图本身不能跨数据库实例或跨厂商数据库（如 MySQL + Oracle + SQL Server）直接整合数据——它只是一条保存的 SELECT 语句，运行时仍受限于当前数据库引擎的能力边界。想用视图“统一查”多厂商数据，必须先让这些数据在**同一个数据库实例里可访问**。
MySQL 中用 FEDERATED 引擎接入其他 MySQL 实例
这是 MySQL 原生支持的跨实例方式，但仅限同构（MySQL → MySQL），且默认关闭、需手动启用：
- 目标库需开启
federated存储引擎：INSTALL PLUGIN federated SONAME 'ha_federated.so'（Linux）或检查show engines是否为YES - 在本地库建
FEDERATED表，指向远程 MySQL 的表：CREATE TABLE remote_users (id INT, name VARCHAR(50)) ENGINE=FEDERATED CONNECTION='mysql://user:pass@192.168.1.100:3306/db1/users' - 之后就能在视图里
UNION ALL本地表和这个remote_users表——但注意：远程表不支持WHERE下推到远端执行，所有数据会拉到本地再过滤，性能极差 - 失败现象常见：
ERROR 1429 (HY000): Unable to connect to foreign data source，多因网络、权限或连接字符串格式错误（如密码含特殊字符未 URL 编码）
PostgreSQL 中用 postgres_fdw 接入其他 PostgreSQL 实例
比 MySQL 的 FEDERATED 更成熟，支持条件下推、列裁剪和部分聚合下推：
- 先安装扩展：
CREATE EXTENSION postgres_fdw - 创建服务器对象：
CREATE SERVER remote_pg FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.168.1.200', port '5432', dbname 'prod') - 映射用户：
CREATE USER MAPPING FOR current_user SERVER remote_pg OPTIONS (user 'reader', password 'xxx') - 导入远程表结构：
IMPORT FOREIGN SCHEMA public FROM SERVER remote_pg INTO local_schema - 视图中可直接引用
local_schema.remote_orders，WHERE order_time > '2026-06-01'会被下推到远端执行——前提是远端该字段有索引 - 坑点：若远端表用
TEXT，本地视图里对应字段也得声明为TEXT，CHAR(20)和TEXT在UNION ALL里会报类型不匹配
SQL Server 中用链接服务器（Linked Server）接入异构源
支持接入 Oracle、MySQL、PostgreSQL（需装对应 OLE DB 或 ODBC 驱动），但视图定义里写法笨重、性能不可控：
- 用
sp_addlinkedserver添加远程服务器，例如 Oracle：@provider='OraOLEDB.Oracle', @datasrc='ORCL' - 视图中引用语法为：
SELECT * FROM [ORCL]..[SCHEMA].[TABLE]（注意是两个点..，不是三个） -
UNION ALL时，所有字段必须显式写出，禁用*；Oracle 的NUMBER映射到 SQL Server 的DECIMAL，需用CAST统一，否则建视图失败 - 最常踩的坑：查询实际执行时，SQL Server 默认把整个远程表拉到本地再做
JOIN或WHERE，导致超时；解决办法是用OPENQUERY强制下推：SELECT * FROM OPENQUERY(ORCL, 'SELECT id, name FROM users WHERE dt >= ''2026-06-01''') -
OPENQUERY不支持参数化，日期得拼字符串，容易被 SQL 注入，生产环境慎用
真正跨厂商的务实做法：别硬塞进视图
当数据源包含 MySQL + Oracle + MongoDB（通过 Connector）时，强行用视图统一查询只会带来维护噩梦和性能黑洞。更可行的路径是：
- 在 ETL 层（如 Airflow + Spark 或 Flink）把各源数据抽取、清洗、对齐主键和字段类型后，落地到统一数仓（如 PostgreSQL 或 ClickHouse）的宽表中
- 在这个数仓里建标准
UNION ALL视图，此时所有字段类型、顺序、NULL 性都可控，索引也能按需加 - 报表或应用只查这个数仓视图，不再感知底层多源差异
- 同步延迟由 ETL 任务控制（如每 15 分钟跑一次），而非依赖数据库原生机制——后者在跨厂商场景下基本不可靠
字段顺序错一位、类型没显式转换、WHERE 没下沉、索引缺失——这四点只要占一个，视图就可能查不出数据或慢到超时。跨厂商场景下，问题往往不是出在视图语法本身，而是你根本没真正把数据“拉平”过。
