Remote Join 比本地 JOIN 慢得多是因为SQL Server无法下推连接逻辑，需将远程表全量数据拉至本地执行JOIN等操作，受网络带宽和序列化开销制约；优化方式包括在远程建带过滤的视图、用OPENQUERY强制下推、显式指定列避免大字段传输。
Remote Join 为什么比本地 JOIN 慢得多
因为 SQL Server 在执行跨服务器 JOIN（比如通过 OPENQUERY、四部分命名 [server].[db].[schema].[table] 或 linked server）时，无法将连接逻辑下推到远程端。默认行为是：把两个远程表的全量或大范围数据拉到本地，再由本地 SQL Server 做 JOIN、WHERE、GROUP BY 等操作。网络带宽和序列化开销成了瓶颈，不是 CPU 或内存。
用远程视图封装 JOIN 逻辑
在远程数据库上预先建好视图（或内联表值函数），把 JOIN、过滤、投影都固化在远程端执行。本地只查这个视图，传输的只是最终结果集。
- 远程建视图示例：
CREATE VIEW dbo.v_remote_orders_customers AS SELECT o.OrderID, o.OrderDate, c.CompanyName, c.Country FROM Orders o INNER JOIN Customers c ON o.CustomerID = c.CustomerID WHERE c.Country = 'China';
- 本地查询只需：
SELECT * FROM [remote_srv].[Northwind].[dbo].[v_remote_orders_customers] - 关键点：视图里必须包含所有必要过滤（
WHERE）、连接和列裁剪（避免SELECT *），否则优化器可能不走下推 - 注意权限：远程视图的执行上下文需有访问基表的权限，且 linked server 登录映射要正确
改用 OPENQUERY 强制下推
OPENQUERY 能绕过 SQL Server 的本地优化器，把整个查询字符串原样发给远程服务器执行，天然支持下推。
- 写法必须严格：
SELECT * FROM OPENQUERY([remote_srv], 'SELECT o.OrderID, c.CompanyName FROM Orders o JOIN Customers c ON o.CustomerID = c.CustomerID WHERE c.Country = ''China''') - 单引号要转义（用两个
''），不能用参数化，SQL 字符串在本地拼接时容易注入，务必校验输入 - 不支持直接引用本地变量，如需动态条件，得用
EXEC()拼接，但会失去执行计划缓存优势 - 如果远程是 Oracle/MySQL，注意语法兼容性；SQL Server 对 SQL Server 最稳
避免 SELECT * 和大字段在 Remote Join 中出现
远程 JOIN 的数据传输量直接取决于「本地需要哪些列」和「远程返回哪些行」。哪怕只多一个 TEXT 或 XML 列，也可能让传输时间翻倍。
- 永远显式列出所需列，禁用
SELECT *，尤其在四部分名或OPENQUERY中 - 远程视图里就该去掉
Notes、Description这类大字段，除非业务真需要 - 如果远程表有
ROWVERSION或计算列，确认它们是否被无意带出 —— 它们不参与业务逻辑，但占带宽 - 用
SET STATISTICS IO ON和SET STATISTICS XML ON对比本地 JOIN 和远程视图的逻辑读与数据流大小
远程 JOIN 的性能陷阱不在语法对错，而在“你以为它在远程算，其实它在本地拉”。只要有一处没封死（比如视图里漏了 WHERE，或 OPENQUERY 里用了本地变量），整条链路就会退化成全量搬运。
