跨库视图必须用四部分命名法，即[databasename].[schemaname].[objectname]，禁止省略数据库名；sql server不允许视图中使用变量或动态库名，所有跨库引用须写死；use切换上下文无效，解析始终基于创建时所在库；数据库名含特殊字符需用方括号包裹；源库重命名或脱机会导致视图查询直接失败；跨库join内存优化表不被支持；建议用openquery强制下推查询以避免全表拉取。
跨库视图必须用四部分命名法，不能省略数据库名
SQL Server 不允许在视图定义中使用变量或动态数据库名，所有跨库引用必须写死为 [DatabaseName].[SchemaName].[ObjectName]。如果你试图用 USE OtherDB 切换上下文再建视图，会失败——视图的解析上下文始终是创建时所在的数据库。常见错误是漏写数据库名，比如写成 SELECT * FROM dbo.Users，结果运行时报错 Invalid object name 'dbo.Users'，因为 SQL Server 默认查当前库，而表实际在另一个库。
- 必须显式写出完整四段式名称：
[SourceDB].[dbo].[Users] - 数据库名带特殊字符（如短横线、数字开头）必须用方括号包裹，否则语法报错
- 视图创建后，若源数据库被重命名或脱机，查询该视图会直接失败，不会静默降级
避免在视图里 JOIN 跨库大表，尤其含内存优化表时
SQL Server 对跨库查询有隐式限制：如果查询中同时涉及内存优化表和常规表，且跨库访问远程表，会触发 The query references a memory-optimized table across databases, which is not supported 错误。这不是权限问题，而是引擎层硬性约束。即便你只是 SELECT，只要执行计划里出现跨库 + 内存优化组合，就会中断。
- 内存优化表所在数据库不能作为远程端参与跨库 JOIN；它只能是本地端
- 若目标是把 PostgreSQL 或 Oracle 数据拉进 SQL Server 做关联，务必用
OPENQUERY或链接服务器封装成“黑盒”，避免优化器尝试下推 JOIN 条件 - 大表跨库 JOIN 容易引发网络传输瓶颈，建议先用
SELECT ... INTO #temp把远程小结果集落地为临时表，再与本地表关联
链接服务器视图需显式配置登录映射，否则查不到数据
用 sp_addlinkedserver 创建链接服务器后，SQL Server 默认不转发当前登录凭据。即使你用 Windows 身份登录本地实例，远程 PostgreSQL 或另一台 SQL Server 仍会收到匿名连接，导致查询返回空或权限拒绝。错误信息通常是 Login failed for user '(null)' 或 Access denied。
- 必须配
sp_addlinkedsrvlogin显式绑定本地登录到远程用户名/密码 - 对 PostgreSQL，推荐用
MSOLEDBSQL提供程序而非已废弃的SQLNCLI，且连接字符串中要明确指定Encrypt=yes和TrustServerCertificate=no - 测试连通性别只靠
SELECT TOP 1 FROM [LinkedSrv].[DB].[sch].[tbl]，要加SET STATISTICS IO ON看是否真走远程，还是被优化器短路成元数据查询
视图性能取决于底层查询可下推程度，不是加索引就能解决
分布式视图本身不存储数据，也不支持直接建索引（除非是索引视图，但跨库场景下索引视图不被允许）。它的性能完全由 SQL Server 查询优化器能否把 WHERE、JOIN、TOP 等条件“下推”到远程端执行决定。如果远程数据库是 PostgreSQL，而你在视图里写 WHERE CreatedDate > '2025-01-01'，SQL Server 可能把它当过滤条件留在本地做，意味着先把全表拉过来再筛——这在百万行级别上会卡死。
- 用
OPENQUERY替代四部分名，能强制把整个子查询发给远程执行，例如SELECT * FROM OPENQUERY(PG_Srv, 'SELECT id,name FROM users WHERE status=''active''') - 避免在视图定义里用
GETDATE()、NEWID()这类非确定性函数，它们无法下推，会导致整表扫描 - 远程表字段类型若与本地不兼容（如 PostgreSQL 的
JSONB对应 SQL Server 的NVARCHAR(MAX)），可能触发隐式转换，阻断下推
真正难处理的，是那些你以为“只是换个数据库名”的简单改动——比如把 [OldDB] 改成 [NewDB]，结果发现新库启用了内存优化，或远程端换了认证方式，或网络策略加了 TLS 版本限制。这些细节不会报错在 CREATE VIEW 阶段，而是在第一次 EXECUTE 时才暴露。
