怎样在SQL中跨多个物理数据库创建统一的业务抽象视图？-SQL-PHP中文网

create view本身不支持跨物理数据库直接引用表，必须依赖数据库扩展机制：postgresql用postgres_fdw、sql server用链接服务器、mysql需应用层兜底或同步；真跨源需联邦查询或etl预整合。

怎样在sql中跨多个物理数据库创建统一的业务抽象视图？

CREATE VIEW 本身不支持跨物理数据库（即不同 DBMS 实例或跨服务器）直接引用表，除非底层数据库明确支持联邦查询或外部数据源能力。多数场景下，“跨多个物理数据库”实际指“跨多个 schema 或 catalog”，或需借助特定数据库的扩展机制。

PostgreSQL 中用 `postgres_fdw` 连接远程数据库再建视图

PostgreSQL 允许通过 postgres_fdw（Foreign Data Wrapper）把另一个 PostgreSQL 实例当成本地表来用，这是最接近“跨物理数据库建视图”的标准方案。

必须在本地库中安装并启用 postgres_fdw 扩展：CREATE EXTENSION postgres_fdw;
创建服务器对象指向远端实例：CREATE SERVER remote_db FOREIGN DATA WRAPPER postgres_fdw OPTIONS (host '192.168.1.100', port '5432', dbname 'sales');
创建用户映射：CREATE USER MAPPING FOR current_user SERVER remote_db OPTIONS (user 'reader', password 'xxx');
导入远端表结构（可选但推荐）：IMPORT FOREIGN SCHEMA public FROM SERVER remote_db INTO local_remote;
然后就能在 CREATE VIEW 中像用本地表一样 JOIN 本地表和 local_remote.orders

⚠️ 注意：远端查询会带来网络延迟，且 WHERE 条件下推依赖优化器能力；聚合、排序尽量在远端完成，否则可能拉全量数据到本地。

MySQL 不支持原生跨实例视图，需用 `FEDERATED` 引擎（已弃用）或应用层兜底

MySQL 8.0+ 已移除 FEDERATED 存储引擎，默认不可用；即使旧版本启用，也存在严重限制：

远程表必须有主键，否则 INSERT/UPDATE 失败
不支持事务一致性，本地事务无法包含远端操作
错误信息模糊，连接中断时视图查询直接报 ERROR 1429 (HY000): Unable to connect to foreign data source

更现实的做法是：

DrugBank 数据库

访问并分析来自 DrugBank 数据库的全面药物信息，包括药物属性、相互作用、靶点、通路、化学结构和药理学数据。用于药物数据、药物发现研究、药理学研究、药物-

下载

在应用层合并查询结果（如用 Python/PgSQL 脚本分别查两个库，内存中 join）
或用中间件（如 vitess、dbt、Materialize）做逻辑建模
或定期将远端数据同步到本地宽表，再基于该宽表建 VIEW

SQL Server 的 `OPENQUERY` 或四部分命名法仅限同域 SQL Server 实例

SQL Server 支持类似 SELECT * FROM [remote_server].[db_name].[schema].[table] 的四部分命名，但前提是：

远程实例已配置为链接服务器（sp_addlinkedserver）
网络互通、端口开放、登录权限正确（常因 NT AUTHORITY\ANONYMOUS LOGON 报错）
视图定义中若含 OPENQUERY，则无法被索引视图引用，也不能参与某些查询重写

示例：

CREATE VIEW unified_customer AS
SELECT c.name, o.total_amount
FROM dbo.customers c
JOIN OPENQUERY(REMOTE_SALES, 'SELECT customer_id, SUM(amount) AS total_amount FROM orders GROUP BY customer_id') o
  ON c.id = o.customer_id;

⚠️ OPENQUERY 内部 SQL 不受本地参数化影响，字符串拼接易引发注入；且每次执行都重新发起远程请求，无缓存。

复杂点在于：所谓“统一业务抽象”，本质是逻辑层整合，而数据库层天然倾向封闭。真正稳定的跨库视图，几乎总要依赖额外组件（FDW / 链接服务器 / ETL / 流处理），而不是单靠 CREATE VIEW 一行语句搞定。别指望视图自动解决分布式一致性或延迟问题——它只是把“怎么查”封装了，没改变“从哪查、查多慢、查得准不准”。