5个表是临界点，因优化器搜索路径呈阶乘级增长（如6表达720种顺序），导致编译耗时飙升、统计失真、退化为次优计划，且中间结果可能指数膨胀，常见现象包括Block Nested Loop、Using temporary、type=ALL及rows严重高估。
超过5个表的JOIN，基本已经超出数据库优化器的合理处理范围，必须拆解，不能硬扛。
为什么5个表是临界点
MySQL、SQL Server、PostgreSQL 的查询优化器在面对 5+ 表 JOIN 时，搜索最优执行路径的组合数呈阶乘级增长（比如6表JOIN有720种连接顺序），导致编译耗时飙升、统计信息失真、最终退化为次优计划。更关键的是，每多一个表，中间结果集就可能指数膨胀——哪怕每张表只返回1万行，6表笛卡尔积理论上限就是 10⁶⁶ 行。
常见错误现象包括：Using join buffer (Block Nested Loop)、Using temporary、type=ALL，以及 EXPLAIN 中 rows 列远超实际业务数据量。
- INNER JOIN 多于5张表，99% 的情况说明业务逻辑或数据建模存在冗余
- 含 LEFT/RIGHT JOIN 的复杂链式关联，极易触发全表扫描，尤其当驱动表无过滤条件时
- 索引再好也救不了：ON 字段有索引，但若前序表没先过滤出小结果集，后续索引形同虚设
用应用层分步查询替代单条大SQL
把原SQL按数据依赖关系切分成 2–3 个独立查询，在代码里组装结果。这不是“绕开SQL”，而是让每一步都可控、可缓存、可监控。
例如原始语句：
SELECT t1.id, t1.name, t2.status, t3.tag, t4.region, t5.score FROM orders t1 JOIN users t2 ON t1.user_id = t2.id JOIN user_tags t3 ON t2.id = t3.user_id JOIN regions t4 ON t2.city_code = t4.code JOIN scores t5 ON t1.id = t5.order_id WHERE t1.created_at > '2026-09-01';
应拆为：
- 第一步查核心订单：
SELECT id, user_id, created_at FROM orders WHERE created_at > '2026-09-01'（加ORDER BY id LIMIT 1000控制批次） - 第二步批量查用户及扩展信息：
SELECT u.id, u.status, r.region, ut.tag FROM users u LEFT JOIN regions r ON u.city_code = r.code LEFT JOIN user_tags ut ON u.id = ut.user_id WHERE u.id IN (/* 上一步的user_id列表 */) - 第三步查分数：
SELECT order_id, score FROM scores WHERE order_id IN (/* 第一步的id列表 */)
注意：第二步用 LEFT JOIN 是安全的，但必须确保 users 表本身已通过 IN 缩小范围；避免在第二步中再带 orders 字段做过滤——那会倒逼数据库重连。
临时表 + 分阶段JOIN（适合无法改代码的场景）
当只能动SQL、不能动应用逻辑时，用临时表显式控制中间结果大小，比让优化器猜要可靠得多。
操作要点：
- 优先物化过滤后的小结果集：
CREATE TEMPORARY TABLE tmp_orders AS SELECT id, user_id FROM orders WHERE created_at > '2026-09-01' LIMIT 5000 - 立刻在临时表上建索引：
CREATE INDEX idx_tmp_user ON tmp_orders(user_id)（MySQL 8.0+ 支持，否则靠主键） - 后续所有 JOIN 都基于
tmp_orders展开，不再触碰原始大表 - 避免
SELECT *：临时表字段只保留真正需要的列，减少内存和I/O压力
特别注意：CREATE TEMPORARY TABLE 在 MySQL 中是会话级的，无需清理；但在 SQL Server 中要用 #tmp 前缀，并注意存储过程嵌套时的作用域问题。
CTE不是银弹，慎用于多表JOIN
CTE（WITH 子句）看起来结构清晰，但多数数据库（尤其是 MySQL 5.7、SQL Server 2016 以前）不会将 CTE 物化，而是将其内联展开——结果仍是单条大SQL，该慢还是慢。
只有满足以下条件时，CTE 才真正有用：
- 数据库版本明确支持物化 CTE（如 PostgreSQL 12+、SQL Server 2019+、MySQL 8.0.22+ 启用
cte_max_recursion_depth） - CTE 内部有强过滤（
WHERE+ 索引字段），且结果集稳定小于 1 万行 - 同一 CTE 被多次引用（否则不如子查询）
反例：WITH a AS (SELECT * FROM big_table), b AS (SELECT * FROM another_big) SELECT * FROM a JOIN b ... —— 这等于没拆，只是换了个写法。
真正该警惕的是：你花10分钟写完 CTE，却没看 EXPLAIN，也没测 tmp_orders 的物理大小。性能调优不靠语法漂亮，靠每一步的 rows 和 key 是否落在预期区间。
