视图不能直接整合异构数据，必须先通过链接服务器或FDW使远程数据可见，再用OPENQUERY（SQL Server）或postgres_fdw（PostgreSQL）封装查询，且需手动处理类型、时区、字段兼容性及结构变更风险。
视图本身不能直接整合异构数据库网关或链接服务器的数据——它只能封装已存在于当前数据库实例中的可访问对象。所谓“通过视图整合”，本质是先让远程数据在本地“可见”，再用视图封装查询逻辑。
SQL Server 中用 OPENQUERY 封装链接服务器查询
链接服务器（Linked Server）建好后，远程表不能直接参与标准 UNION ALL 或 JOIN（尤其跨厂商时），必须用 OPENQUERY 显式调用，否则报错 Msg 7314 或 Msg 7399。
-
OPENQUERY是唯一能绕过 SQL Server 对远程列元数据校验限制的方式，比如查 Oracle 表的DATE字段，不用提前建同名本地视图也能映射 - 语法必须写全：
SELECT * FROM OPENQUERY(LinkedServerName, 'SELECT id, name, TO_CHAR(created_at, ''YYYY-MM-DD'') AS dt FROM users')—— 注意内部 SQL 是目标库语法，不是 T-SQL - 不能在
OPENQUERY内写参数或变量，所有过滤条件得硬编码或靠外层 WHERE（但大部分情况下不会下推，会全量拉取） - 建视图时，
OPENQUERY必须作为子查询或直接出现在 SELECT 列表中，例如：CREATE VIEW v_remote_users AS SELECT id, name, dt FROM OPENQUERY(OracleLink, 'SELECT ...')
PostgreSQL 中用 postgres_fdw + 视图组合，但别信“自动类型对齐”
即使通过 postgres_fdw 接入了另一个 PostgreSQL 实例，视图里仍要手动处理字段兼容性——FDW 不解决语义差异，只解决连接和基础下推。
- 远程表字段是
TEXT，本地视图定义里也得写col::TEXT；若远程是CHAR(20)，直接UNION ALL会失败，必须显式TRIM(col)::TEXT - 时间字段注意时区：远程用
TIMESTAMP WITHOUT TIME ZONE，本地视图若想统一转成带时区，得写col AT TIME ZONE 'UTC'，否则ORDER BY结果可能错乱 -
IMPORT FOREIGN SCHEMA导入的表名默认带 schema 前缀（如remote_schema.users），视图里引用时不能省略，否则报relation does not exist - 若远程表有生成列或表达式索引，FDW 不识别，视图里对应字段无法利用远端优化，WHERE 条件大概率不被下推
MySQL 的 FEDERATED 引擎 + 视图 = 高风险组合
MySQL 的 FEDERATED 表看似能当本地表用，但和视图叠加后，性能和稳定性问题会被放大，多数生产环境已弃用。
-
FEDERATED表不支持WHERE下推，视图里哪怕写WHERE status = 'active'，也会先把整张远程表拉到本地再过滤 - 远程库连接中断时，视图查询直接报
ERROR 1429，且无重试机制；而原生应用层可以捕获异常并降级 - 密码含特殊字符（如
@、/）必须 URL 编码，否则CONNECTION字符串解析失败，错误提示极不明确 - 视图里混合
FEDERATED表和本地 InnoDB 表做UNION ALL，若本地表有全文索引或 JSON 字段，远程表对应位置补NULL时类型声明必须严格匹配，否则建视图失败
真正容易被忽略的是：所有这些方案都依赖「远程库返回结构稳定」。一旦源库表结构变更（比如 Oracle 表加了个 NUMBER(10,2) 字段，而 MySQL FEDERATED 表没同步改），视图查询就会在运行时报类型不匹配，而不是建视图时报错——这种延迟失败最难排查。
