JOIN字段无索引会导致性能下降约50%，需为外键和关联字段手动创建复合索引，注意数据类型一致、更新统计信息、避免SELECT *、合理控制JOIN顺序及内存配置。
JOIN条件列没索引，性能直接掉一半
SQL Server 2022的查询优化器虽然智能，但不会自动给JOIN字段建索引。如果ON子句里用的列（比如Orders.CustomerID和Customers.CustomerID）没有索引，引擎大概率走Nested Loops或更糟的Merge Join回表扫描，rows值在执行计划里会飙到几十万甚至百万级。
实操建议：
- 对所有
JOIN涉及的外键列、关联字段，手动创建索引——不只是单列，优先考虑复合索引，顺序按WHERE过滤 +JOIN条件排列 - 用
sys.dm_db_missing_index_details查缺失索引建议，但别全信，要结合实际查询模式验证 - 注意数据类型一致性：比如
INT和BIGINT隐式转换会让索引失效，执行计划里Warnings会标出Convert
多表JOIN时顺序不对，优化器可能选错驱动表
SQL Server 2022默认用统计信息估算行数来决定驱动表（outer table），但如果某张小表被误判为大表，就会让大表做内循环，拖慢整个JOIN。典型现象是执行计划里出现大量Hash Match但Build Cost远高于Probe Cost。
实操建议：
- 用
OPTION (FORCE ORDER)临时控制JOIN顺序，验证是否改善；长期方案是更新统计信息：UPDATE STATISTICS+WITH FULLSCAN - 避免在JOIN链中混用
LEFT JOIN和INNER JOIN，尤其当LEFT侧表无过滤条件时，容易让优化器误估基数 - 把带强过滤条件（如
WHERE Status = 'Active'）的表放在JOIN链靠前位置，帮优化器早剪枝
SELECT * + 多层嵌套JOIN，内存压力和网络开销翻倍
不是所有字段都需要JOIN出来。用SELECT *会让SQL Server 2022在JOIN过程中搬运整行数据，即使最终只用其中2列。这会显著拉高tempdb使用、增加序列化/反序列化开销，尤其在并行执行时线程间内存争用加剧。
实操建议：
- 显式列出需要的列，禁止
SELECT *——哪怕开发阶段图省事，上线前也必须改 - 对宽表JOIN，考虑提前用CTE或视图预聚合，比如把
Sales和Products的常用组合字段提前算好存成v_sales_summary - 检查执行计划里的
Columnstore Index是否启用：2022对列存JOIN支持更好，但要求至少两张表都建了列存索引，且JOIN列在索引键里
哈希JOIN在内存不足时降级成Spill，I/O爆炸
SQL Server 2022默认倾向用Hash Join处理中等规模JOIN，但它依赖内存。如果max server memory设得太低，或并发查询太多，哈希构建阶段就会写入tempdb，执行计划里显示Warning: Hash warning: Hash bailout，I/O瞬间飙升。
实操建议：
- 监控
sys.dm_exec_query_stats里total_logical_reads和total_physical_reads比值，持续偏高说明Spill频繁 - 调大
max server memory（建议设为物理内存的75%~80%），同时确保tempdb文件数=CPU核心数，且每个文件大小均等 - 对已知大数据量JOIN，主动用
OPTION (HASH JOIN)或OPTION (MERGE JOIN)干预，比让它自己瞎猜更稳
真正卡住性能的往往不是JOIN语法本身，而是统计信息过期、内存配置僵硬、或者开发时没意识到SELECT *在JOIN场景下放大了多少倍的资源消耗。调优得盯着执行计划里的Actual Rows vs Estimated Rows差多少，而不是只看有没有红色警告图标。
