JOIN慢的核心是中间结果集失控，应优先用高选择性表驱动、小表驱动大表，LEFT JOIN右表过滤条件须放ON子句，避免误转INNER JOIN，并先排查单表全表扫描瓶颈。

三表以上JOIN慢，核心问题往往不在SQL写法本身，而在于中间结果集失控——先连两个大表，再连第三个表时，临时行可能已膨胀到百万级，哪怕最终WHERE只留10条也没用。

为什么JOIN顺序直接影响执行效率

数据库优化器会重排JOIN顺序，但你写的顺序决定了中间结果集的“初始膨胀点”。比如orders JOIN users JOIN products，若orders和users都无过滤条件，光这两张表笛卡尔积就可能超千万行，再连products只会雪上加霜。

• 用EXPLAIN看rows列：如果某次JOIN前的rows突然跳到几十万，说明它就是膨胀源头
• 高选择性表优先：带强WHERE条件（如status = 'paid'）的表应尽量放在JOIN链开头，让中间结果从一开始就被压小
• 小表驱动大表仍是有效经验：比如class表只有20行，student有10万行，先class JOIN student比反过来更稳
• MySQL中可用STRAIGHT_JOIN强制顺序，但前提是ANALYZE TABLE已更新统计信息，否则可能适得其反

LEFT JOIN后对右表字段加WHERE等于变INNER JOIN

这是线上事故高频点。写成LEFT JOIN b ON a.id = b.a_id WHERE b.status = 'paid'，实际效果等同于INNER JOIN——因为WHERE会把右表为NULL的记录全过滤掉。

• 正确做法是把右表过滤条件挪进ON子句：LEFT JOIN b ON a.id = b.a_id AND b.status = 'paid'
• 检查EXPLAIN的Extra列：若出现Using where且涉及右表字段，就是危险信号
• 如果业务真需要“左表全量 + 右表按状态匹配”，但又想保留NULL行，必须确认右表该字段允许NULL，否则LEFT JOIN失去意义

物化视图不是万能解药，MySQL原生不支持

PostgreSQL、Oracle或SQL Server可建物化视图缓存多表JOIN结果，但MySQL直到8.0仍无原生物化视图支持。强行模拟（如用定时INSERT INTO ... SELECT刷新临时表）反而容易引发一致性问题。

• 真正可行的替代方案是：对稳定维度表（如course、class）与事实表（如score）的常用组合，建宽表并每日增量更新
• 宽表字段命名需带来源标识，比如course_subject、class_name，避免后续JOIN时字段歧义
• 如果只是为提速报表查询，优先考虑在应用层做二级缓存（如Redis存聚合结果），比数据库层硬扛JOIN更可控
• 注意宽表索引策略：复合索引要覆盖常用查询条件，比如报表常查class_name = '高三(1)班' AND course_subject = 'Python编程'，那就建(class_name, course_subject)索引

最易被忽略的点是：你以为在优化JOIN，其实瓶颈可能在单表扫描——比如orders表没对order_date建索引，那无论怎么调JOIN顺序，第一步扫全表就已注定慢。先看EXPLAIN里哪个表的type是ALL，再动手。