JOIN变慢主因是SQL Server强制加载LOB页，即使只取1行也可能触发数MB磁盘读；应通过CTE或子查询剥离LOB字段，仅用轻量字段JOIN，并确保过滤和连接字段有索引。
为什么JOIN一碰LOB字段就变慢
不是因为数据量大，而是SQL Server在JOIN过程中只要看到VARCHAR(MAX)、NVARCHAR(MAX)、XML这类LOB列出现在SELECT、ON、WHERE或ORDER BY里，就会强制加载整块LOB页——哪怕你只取1行，也可能触发数MB的磁盘读。执行计划里出现高LOB Logical Reads或频繁Worktable操作，基本就是它在拖后腿。
- LOB列无法建B-tree索引，
INCLUDE也不能包含它们 -
TEXT/NTEXT已弃用，但存量系统仍有；VARCHAR(MAX)超过8000字节时自动转为LOB存储 - 即使没显式SELECT大字段，只要该表是LEFT JOIN的左表，且统计信息过期，优化器可能误选Nested Loop，每行都触发LOB定位开销
用CTE或派生表提前剥离LOB字段
核心原则：让JOIN只发生在轻量字段上。先用WHERE过滤+索引驱动选出主键/外键集，再按需回查LOB。这能将LOB加载总量从“全表×匹配行数”压到“结果集×1”。
- 确保子查询中用到的过滤字段（如
status、created_date）有索引，连接字段（如order_id）有外键索引或单独索引 - 避免在CTE里SELECT任何LOB列，只保留JOIN键和WHERE条件列
- 后续JOIN原表时，只SELECT真正需要的LOB字段，别写
SELECT *
WITH light_orders AS ( SELECT order_id, customer_id FROM orders WHERE status = 'shipped' AND created_date >= '2025-01-01' ) SELECT o.order_id, o.customer_id, d.detail_text FROM light_orders o INNER JOIN order_details d ON o.order_id = d.order_id;
绝对不要在JOIN条件里对LOB字段做运算
哪怕只是LEN(detail_text) > 100或detail_text LIKE '%error%'，都会让优化器放弃所有索引，强制逐行加载LOB并计算——全表扫描不可避免。
- 禁止写
ON t1.desc = t2.desc（两边都是NVARCHAR(MAX)） - 全文检索必须显式用
CONTAINS或FREETEXT，不能靠LIKE兜底 - 如果业务真要按内容过滤，优先考虑加计算列+索引，或拆出摘要字段（如
summary_hash）做等值匹配
LEFT JOIN场景下LOB字段更危险
LEFT JOIN强制左表作为驱动表，优化器无法重排顺序。一旦左表含LOB字段且没被前置过滤，每行都会触发一次LOB定位，性能直接崩盘。这时候比优化JOIN本身更重要的是重构数据访问路径。
- 把LEFT JOIN左表的LOB字段彻底移出JOIN主体，改用延迟关联（如用
APPLY或二次查询） - 若必须返回NULL填充的LOB值，可在主查询完成后用
UPDATE或MERGE分批补填，避开JOIN阶段 - 检查执行计划里是否出现
Hash Match但Build Input来自含LOB的表——这是内存和tempdb压力的明确信号
