SQL Server多表JOIN必须显式按驱动表优先级排列，因其不自动选最优顺序；应将过滤最强且带索引的表置于最左作为驱动表，避免中间结果集爆炸，并严格区分ON（连接逻辑）与WHERE（业务过滤），同时剥离大文本字段、规范别名与字段前缀。
JOIN顺序必须按驱动表优先级排列
SQL Server不会自动选最优顺序，尤其五张表以上时，执行计划容易崩。它默认按FROM后出现顺序做驱动，但若第二张表是千万级大表，而第三张表有强WHERE过滤，就会先载入大表再裁剪——中间结果集爆炸。
- 先查每张表的行数和关键字段索引：用
sp_spaceused看实际大小，别信“小表”直觉 - 把过滤条件最强（比如
WHERE status = 'completed' AND created_date > '2025-01-01'）且带有效索引的表放最左，让它当驱动表 - 避免LEFT JOIN后接INNER JOIN再接另一个LEFT JOIN——这种嵌套会让右表空值传播不可控，建议拆成CTE分步处理
- 如果必须保持单条语句，用
OPTION (FORCE ORDER)锁死顺序，但前提是已用EXPLAIN确认该顺序确实减少了rows和tempdb使用
所有ON条件必须严格区分连接逻辑与业务过滤
五张表连在一起时，最容易把本该在WHERE里的条件错塞进ON，尤其LEFT JOIN链中。一旦在第二个LEFT JOIN的ON里写了AND o.status = 'paid'，就等于把第一张左表的空值行全筛掉了，语义彻底变味。
-
ON只放真正定义“怎么连”的字段等值关系，例如u.id = o.user_id、o.id = oi.order_id - 业务过滤一律后置到最终
WHERE，哪怕要重复写字段前缀，比如WHERE u.is_active = 1 AND o.amount > 100 - 多表LEFT JOIN中，后续ON可引用前面所有表字段，但别滥用——比如
ON d.dept_id = u.dept_id AND d.region = 'CN'，region条件应挪到WHERE，否则d表会提前被过滤，导致u表关联不到其他region用户
大文本字段必须从JOIN路径中剥离
只要任意一张参与JOIN的表含VARCHAR(MAX)、NTEXT或XML字段，哪怕SELECT里没取它，SQL Server也可能因统计误判或执行计划退化，强制加载LOB页，五表JOIN瞬间变卡死或报ERROR 701。
- 用CTE或派生表提前抽轻量主键+筛选字段，例如：
WITH light_orders AS (SELECT order_id, user_id FROM orders WHERE status = 'shipped') - 确保该子查询能走索引——检查
user_id和status是否在同一个复合索引里，且顺序匹配 - 再用这个结果集去JOIN其他四张表，最后才通过主键回查大字段，例如
JOIN order_details d ON lo.order_id = d.order_id - 绝对不要在任何ON或WHERE里对大字段做
LIKE、LEN()、CONVERT()等操作，这会直接触发全表扫描+LOB逐行加载
显式别名与字段前缀是可读性底线
五张表连写，不加前缀的id、name、created_date满天飞，不仅人看不懂，SQL Server解析器也容易歧义，甚至生成错误执行计划。
- 每张表必须声明短且明确的别名：
users u、orders o、order_items oi、products p、categories c - SELECT和ON里所有字段必须带前缀，禁止
SELECT id, name，必须写SELECT u.id, u.name, o.order_no - 避免别名冲突：比如
customers c和categories c不能共存，改用cust或cat - 字段太多时，宁可分行写，也不要省略前缀——换行成本远低于查错一小时
