根本原因是SQL Server默认不将JOIN、WHERE、GROUP BY下推到远程端，而是先拉取全量数据到本地再计算，导致网络流量与结果集大小无关；可用OPENQUERY强制下推、显式列选择、临时表分步等方法优化。
为什么远程 JOIN 会把内网带宽打满
根本原因不是“数据多”，而是 SQL Server 默认不把 JOIN、WHERE、GROUP BY 下推到远程端。它会先把两张远程表的全量数据（或大范围扫描结果）拉到本地，再由本地引擎做关联——哪怕你只想要 10 行，也可能先拖回几十万行原始记录。网络流量 = 远程表 A 行数 × 平均行宽 + 远程表 B 行数 × 平均行宽，和最终结果集大小完全无关。
用 OPENQUERY 强制下推计算逻辑
OPENQUERY 是唯一能绕过默认拉取行为的方式，它把整段 SQL 发送到远程服务器执行，只传回最终结果。但必须注意语法细节：
- 不能用四部分命名（如
LS1.DB1.dbo.T1），必须写成OPENQUERY(LS1, 'SELECT id, name FROM DB1.dbo.T1 WHERE status = ''active''') - 字符串参数里的单引号要双写（
''active''），否则报错Msg 7321, Level 16, State 2 - JOIN 必须写在远程 SQL 内：
OPENQUERY(LS1, 'SELECT a.id, b.order_no FROM DB1.dbo.users a JOIN DB2.dbo.orders b ON a.id = b.user_id WHERE a.created >= ''2026-06-01''') - 远程表字段类型要显式兼容，比如 MySQL 的
DATETIME和 SQL Server 的datetime2直接 JOIN 可能失败，加CONVERT(varchar, b.created, 120)更稳
避免 SELECT * + 大字段传输
跨库 JOIN 最容易被忽略的放大器是字段体积。一个 text 或 varbinary(max) 字段，每行多传 1MB，1000 行就是 1GB 流量。
- 永远显式列出需要的列，删掉所有
* - 远程表有
image、xml、json字段？用NULL占位或LEFT(remark, 200)截断 - 如果远程是 MySQL，
FEDERATED引擎默认把TEXT当LONGBLOB拉，比预期大 3 倍，必须用CAST(content AS CHAR(500))显式转换 - 检查执行计划里是否出现
Remote Query算子——没出现说明下推失败，还在走默认拉取路径
用临时表分步控制流量峰值
当 OPENQUERY 也不适用（比如远程权限受限），就退一步：把 JOIN 拆成两步，用本地临时表做缓冲，人为限流。
- 第一步：用带
WHERE的SELECT INTO #temp_a拉少量关键 ID 和关联字段（如user_id,status），控制在 1 万行以内 - 第二步：用
IN或EXISTS查远程表，注意IN列表长度限制（max_allowed_packet影响 MySQL；SQL Server 对IN参数个数无硬限，但超过 2000 个建议改用临时表 JOIN） - 别在临时表上建索引后立刻 JOIN——
#temp_a数据少时，哈希匹配比索引查找更快；只有 >5 万行才考虑CREATE INDEX IX_user_id ON #temp_a(user_id) - 临时表记得
DROP TABLE #temp_a，否则下次执行可能因对象已存在报错Msg 2714
真正卡住人的从来不是“能不能连上”，而是“连上了却不知道数据正在哪条网线里排队”。只要远程计算没下推，再快的万兆内网也会在 10 万行 JOIN 时变成瓶颈。盯住执行计划里的数据移动量，比调优语句本身更关键。
