CREATE VIEW本身不处理跨库访问，仅封装SELECT语句；能否跨库取决于该SELECT在当前数据库是否可直接执行、权限是否满足及目标对象是否存在，且各数据库系统支持方式差异显著。
CREATE VIEW 本身不解决跨库问题，它只是封装一个合法的 SELECT。能不能跨库，取决于你写的那条 SELECT 在当前数据库里是否能直接执行成功——而这个“能否执行”，各系统差异极大，不能套用同一套逻辑。
SQL Server 直接写三段式或四段式名建视图
同实例不同库，直接用 [db_name].[schema_name].[table_name] 就行，比如：SELECT * FROM [SalesDB].[dbo].[Orders] JOIN [FinanceDB].[dbo].[Invoices]。建视图时必须写满三段，SalesDB..Orders（缺 schema）会报 Invalid object name。
权限检查发生在运行时，不是创建时——所以 CREATE VIEW 成功，不代表 SELECT 视图时不报 Permission denied。要查得通，用户得对两个库都有 SELECT 权限。
跨实例必须配链接服务器（Linked Server），再用四段式：[linked_server].[db_name].[schema].[table]。否则必报 Msg 7314。配置后还得在“服务器选项”里把 RPC Out 设为 True，不然 OPENQUERY 调不了远程聚合函数。
MySQL 同实例跨库只需权限+全限定名
MySQL 允许在 SELECT 里直接写 db1.users JOIN db2.logs，只要当前用户对 db1 和 db2 都有 SELECT 权限，就能建、能查。
不需要 FEDERATED 引擎——那是为跨 MySQL 实例准备的。同实例跨库，FEDERATED 是绕远路。
注意字段名冲突：两个库都有 id 字段，必须用别名明确区分，否则 SELECT * 会出错；GROUP BY 查询若没显式列出所有非聚合列，在 ONLY_FULL_GROUP_BY 模式下会建失败。
PostgreSQL 必须用扩展，不能直写其他库名
PostgreSQL 实例内各数据库完全隔离，CREATE VIEW 里写 other_db.public.table 是非法语法，直接报 cross-database references are not implemented。
唯一可行路径是先 CREATE EXTENSION dblink 或 postgres_fdw：
-
dblink：每次调用都新建连接，适合低频、小结果集；dblink('conn_str', 'SELECT...')返回SETOF record，必须用AS (col1 type1, col2 type2)显式声明结构，否则视图建不起来 -
postgres_fdw：支持谓词下推，性能好得多，但配置链长——CREATE EXTENSION（需超级用户）、CREATE SERVER（host和dbname必须显式写出，port别省略）、CREATE USER MAPPING（凭据是远程库账号，不是本地用户）
FEDERATED / postgres_fdw / Linked Server 都不自动下推计算
跨库视图慢，通常不是因为“跨库”本身，而是底层没把 WHERE、ORDER BY、LIMIT 发到远程执行。关键看执行计划：
- MySQL FEDERATED 完全不支持下推，远程只返回全表，所有过滤都在本地做
- PostgreSQL
postgres_fdw支持大部分下推，但复杂表达式（如UPPER(col)、子查询）仍会回本地处理；EXPLAIN看到Foreign Scan后带Remote SQL才算真正下推 - SQL Server 的
OPENQUERY可以下推，但普通四段式写法默认不保证——想稳定下推，就得用OPENQUERY显式包裹远程语句
别在视图里写 SELECT *，尤其远程表字段多时；远程表没索引，下推了 WHERE 也白搭。
