多表JOIN慢主因是索引缺失、JOIN顺序错乱、条件未下推；EXPLAIN显示type=ALL或rows巨大表明全表扫描；LEFT JOIN右表条件须写在ON中，否则退化为INNER JOIN；哈希连接需等值条件且MySQL 8.0+支持；超5万行中间结果宜改用应用层组装。
多表JOIN慢，八成不是SQL写得丑，而是没让MySQL“看清路”——索引缺失、JOIN顺序错乱、条件没下推，这三样占了90%的性能问题。
为什么EXPLAIN显示type=ALL或rows巨大
这是最直接的信号：MySQL正在全表扫描某张表。常见原因包括连接字段没索引、复合索引顺序不对、或者WHERE条件写在LEFT JOIN之后却误用了右表字段。
-
ON子句里的字段必须有索引，且最好是联合索引（如orders(user_id, status)比单列user_id更利于过滤+连接） - 对
LEFT JOIN，若在WHERE里写o.order_date > '2023-01-01'（o是右表别名），会把LEFT退化成INNER——正确写法是把条件挪到ON里：LEFT JOIN orders o ON c.id = o.customer_id AND o.order_date > '2023-01-01' - 执行
EXPLAIN FORMAT=JSON时，重点看"hash_join": true是否出现——MySQL 8.0+才支持哈希连接，它比嵌套循环快得多，但只适用于等值JOIN且内存充足
什么时候该放弃12表JOIN，改用应用层组装
当EXPLAIN中出现Using temporary或Using filesort，且中间结果集预计超5万行时，硬扛JOIN不如拆开。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 先查主表（如
orders）加必要过滤，拿到order_id列表（控制在1000以内） - 用
IN批量查关联表：SELECT order_id, product_id FROM order_items WHERE order_id IN (…)，避免N+1 - Java/Go里用Map按
order_id归并，比数据库做12表JOIN省内存、易调试、还能加缓存 - 阿里规范禁三表以上JOIN，不是拍脑袋——每多一个JOIN，优化器决策空间指数级增长，容易选错驱动表
join_buffer_size设多大才不浪费也不溢出
这个参数管的是Block Nested-Loop Join的内存缓冲区，设太小会频繁刷磁盘，设太大又挤占InnoDB buffer pool。
- 默认256KB通常不够，可先调到4MB：
SET SESSION join_buffer_size = 4194304（仅当前会话，上线前需改配置文件） - 观察
SHOW STATUS LIKE 'Select_full_join'：值持续增长说明buffer不够，被迫退化为全表扫描式JOIN - 注意：此参数对
INNER JOIN有效，对LEFT JOIN效果有限——因为左表必须全读入，无法靠buffer跳过 - MySQL 8.0+优先走哈希连接时，
join_buffer_size影响变小，但hash_join_buffer_size要同步调大（默认1MB）
真正卡住性能的往往不是JOIN本身，而是你没意识到：LEFT JOIN的右表条件必须写在ON里、哈希连接需要等值条件、以及应用层组装有时比数据库拼得更稳——这些细节漏掉一个，优化就白做了。
