JOIN 查询变慢主因是优化器选错驱动表或未走索引，须用 EXPLAIN 查看 type、rows、Extra；连接字段类型不一致或复合索引顺序错误会导致索引失效；STRAIGHT_JOIN 需谨慎使用；LEFT JOIN 中过滤条件应优先放 ON 而非 WHERE；join_buffer_size 过小或字段过长会引发磁盘临时表。
为什么 JOIN 查询变慢了？先看执行计划
MySQL 的 JOIN 慢，90% 不是语法问题，而是优化器选错了驱动表或没走索引。必须用 EXPLAIN 看实际执行路径，重点关注 type（是否为 ref/range，避免 ALL）、rows（预估扫描行数）、Extra（是否出现 Using join buffer 或 Using temporary）。
常见误判：看到 JOIN 就加索引——但若连接字段类型不一致（比如 INT 对 VARCHAR），索引会失效；或者被驱动表有复合索引但顺序错（如 ON a.x = b.x AND a.y = b.y，但索引是 (y, x)），照样全表扫。
STRAIGHT_JOIN 强制驱动表时要注意什么
当优化器选错驱动表（比如小表没被选为驱动表），可用 STRAIGHT_JOIN 手动指定。但它不是银弹：
- 只对当前语句生效，无法被查询缓存复用（如果还开着的话）
- 如果数据分布变化（比如某表突然膨胀），原来最优的驱动顺序可能变差
- 在从库上执行时，若主从表统计信息不同步，
STRAIGHT_JOIN可能让从库更慢
建议只在明确知道驱动表应为何、且该查询高频稳定时使用；上线前务必在从库也验证 EXPLAIN 输出。
多表 JOIN 时，WHERE 条件放哪儿影响很大
条件写在 ON 还是 WHERE，对结果和性能都可能不同，尤其涉及 LEFT JOIN：
-
ON中的条件用于决定如何匹配，不满足也会保留左表记录（右表字段为NULL） -
WHERE中的条件是在JOIN完成后过滤，会把NULL行直接剔除，等价于转成INNER JOIN
性能上，把能提前过滤的条件尽量塞进 ON（特别是被驱动表的字段），让关联前就缩小结果集。例如：LEFT JOIN order_items oi ON o.id = oi.order_id AND oi.status = 'shipped' 比 LEFT JOIN ... ON o.id = oi.order_id WHERE oi.status = 'shipped' 更高效，后者会先生成大量 NULL 行再过滤。
临时表和排序开销大？检查 join_buffer_size 和字段长度
当 EXPLAIN 显示 Using join buffer (Block Nested Loop)，说明 MySQL 在内存里缓存驱动表部分数据做批量匹配。但这个 buffer 大小受 join_buffer_size 控制，默认才 256KB，很容易溢出，导致磁盘临时表甚至排序。
真正有效的调优点是：
- 确保连接字段类型完全一致（包括字符集、是否
NOT NULL），否则无法使用join buffer - 减少
SELECT *，只查真正需要的字段；过长的VARCHAR或TEXT字段会让每行占用 buffer 更多空间 - 如果必须关联大字段，考虑把关联逻辑提到应用层，用两次查询+内存哈希代替单次
JOIN
别盲目调大 join_buffer_size——它按线程分配，设太高会快速耗尽内存，反而触发 swap。
