MySQL用FEDERATED引擎建视图前必须确认三件事：一是SHOW ENGINES中FEDERATED状态为YES，否则需在my.cnf添加plugin_load_add=federated并重启；二是远程库对应账号已授SELECT权限且host不能仅限localhost；三是本地CREATE TABLE的字段名、类型、顺序必须与远程表完全一致。
MySQL 用 FEDERATED 引擎建视图前必须确认三件事
MySQL 原生不支持跨库 JOIN，所谓“跨库视图”本质是先建一张 FEDERATED 表代理远程数据，再基于它建 VIEW。但很多人卡在第一步就失败，不是语法错，而是三个前提没满足：
-
SHOW ENGINES;返回结果里FEDERATED状态必须是YES；若为NO，需在my.cnf加plugin_load_add = federated并重启服务 - 远程 MySQL 必须给对应账号开放
SELECT权限，且 host 不能只写localhost（本地建表时连的是远程地址） - 本地
CREATE TABLE的字段名、类型、顺序必须和远程表完全一致，哪怕只是VARCHAR(255)vsVARCHAR(191)，也可能导致查询返回NULL或截断
PostgreSQL 用 postgres_fdw 建视图时最容易漏的权限点
PG 的 postgres_fdw 比 MySQL 的 FEDERATED 更可靠，但配置链更长，漏掉任意一环都会让视图查不到数据：
-
CREATE EXTENSION postgres_fdw;必须由超级用户执行，普通用户执行会报错permission denied -
CREATE SERVER中的host和dbname必须显式写出，port不能省略（哪怕用默认 5432）；若连同实例不同库，host得填127.0.0.1，不能填unix_socket_directories路径 -
CREATE USER MAPPING的用户名密码，是远程库的登录凭据，不是本地用户；密码明文存在系统表里，生产环境建议用.pgpass文件或角色密码策略替代
SQL Server 视图里写四段式命名 [server].[db].[schema].[table] 报错怎么办
直接在视图里写 [remote_server].[db_name].[schema].[table] 是可行的，但前提是已正确配置链接服务器（Linked Server），否则报 Msg 7314, Level 16: 无法找到对象：
- 右键 SQL Server Management Studio 中的“链接服务器” → “新建链接服务器”，填好远程服务器地址、认证方式、产品名称（如
SQL Server） - 必须在“服务器选项”里把
RPC Out设为True，否则OPENQUERY无法调用远程聚合函数 - 如果远程是 MySQL/PostgreSQL，需安装对应 ODBC 驱动，并在链接服务器配置中指定
Provider（如MSDASQL）和Data Source
跨库视图性能差？先看执行计划里有没有 Remote SQL
视图本身不解决性能问题，慢是因为数据拉取逻辑没下推。关键看底层是否真正把过滤、分组、排序发到远程执行：
- MySQL
FEDERATED完全不支持谓词下推——WHERE、GROUP BY、JOIN全在本地做，远程只返回整张表；所以大表慎用，优先在远程库建好汇总视图再映射 - PostgreSQL
postgres_fdw在EXPLAIN中看到Foreign Scan后带Remote SQL才算下推成功；若只有Foreign Scan没后续，说明优化器放弃下推，常见原因是 GROUP BY 字段没索引或类型不匹配 - SQL Server 的
OPENQUERY天然支持下推，但内部不能用变量，所有条件得硬编码；动态场景要用EXEC(@sql)包一层，且聚合字段必须带别名，否则本地识别不了列名
跨库视图不是“建完就能跑”，它把数据库之间的网络、权限、类型兼容性、执行计划控制全都暴露在 SQL 层。最容易被忽略的是：远程表结构变更后，本地联邦表或外表不会自动同步，必须手动重建或 IMPORT FOREIGN SCHEMA 刷新。
