MySQL 的 JOIN 查询慢，核心问题通常出在驱动表选择、连接字段索引缺失、数据量预估偏差或临时表/排序开销上。优化不是堆索引，而是理清执行路径，让优化器能选对策略。
确认驱动表是否合理
JOIN 执行时，MySQL 会选定一个表作为“驱动表”（外层循环），逐行去另一张表（被驱动表）查找匹配行。如果小表没当驱动表，大表反而被嵌套遍历，性能会断崖式下跌。
建议：
• 用 EXPLAIN 查看 table 列顺序和 rows 预估值，确认实际驱动表是否是数据量更小、过滤后结果集更少的那张；
• 如果优化器选错（比如因统计信息过期或条件复杂误判），可用 STRAIGHT_JOIN 强制指定驱动表顺序；
• 多表 JOIN 时，避免写成 (A JOIN B) JOIN C 这类固定括号结构，让优化器有重排空间，除非你明确知道顺序更优。
确保连接字段有高效索引
被驱动表的 ON 条件字段必须有索引，否则就是全表扫描——每从驱动表取一行，就要扫一遍被驱动表，复杂度接近 O(N×M)。
注意点：
• 索引要覆盖 ON 子句中的全部列，且顺序尽量匹配（如 ON a.x = b.x AND a.y = b.y，b 表索引应为 (x, y) 而非仅 (x)）；
• 字段类型和字符集必须严格一致，否则索引失效（例如 utf8mb4 和 utf8、DECIMAL(10,2) 和 FLOAT）；
• 若连接条件含函数或表达式（如 ON DATE(create_time) = '2024-01-01'），索引无法使用，需改写为范围查询或增加生成列索引。
减少参与 JOIN 的数据量
越早过滤，JOIN 代价越低。把 WHERE 条件尽可能下推到单表上，而不是等 JOIN 完再过滤。
操作建议：
• 把能独立过滤的条件写在对应表的 WHERE 中（不是全堆在最后），例如 SELECT * FROM user u JOIN order o ON u.id = o.user_id WHERE u.status = 1 AND o.pay_time > '2024-01-01'；
• 对大表 JOIN，可先用子查询或临时表预聚合/预过滤（如只取最近 30 天订单再关联用户），但需权衡临时表开销；
• 避免 SELECT *，只取真正需要的字段，减少网络传输和内存排序压力。
留意隐式转换与 NULL 值影响
字段类型不一致或 NULL 参与比较，不仅让索引失效，还可能改变 JOIN 类型（如转为 ALL 或 Using temporary）。
常见情况：
• 字符串字段用数字查询：WHERE name = 123 → MySQL 会把 name 全部转为数字比较，索引失效；
• LEFT JOIN 后对被驱动表字段加 WHERE 条件（如 WHERE o.amount > 100），会把 LEFT JOIN “降级”为 INNER JOIN，且可能导致全表扫描；
• 连接字段允许 NULL，又没在索引中妥善处理，可能导致索引选择率变差，优化器放弃走索引。
不复杂但容易忽略。关键是在写完 JOIN 后，一定用 EXPLAIN 看一眼，重点关注 type、key、rows、Extra 几列，比盲目加索引更有效。
