JOIN性能关键在被驱动表索引：需建于ON字段（如orders.user_id），类型严格一致；LEFT JOIN右表同样需索引；覆盖索引可减少IO；驱动表选择错误会使索引失效。
JOIN 的索引不是“自动生效”，而是被驱动表用的
很多人以为只要 ON 字段有索引，JOIN 就快——其实索引只对「被驱动表」起作用。数据库执行 JOIN 时，会先选一张表当驱动表（比如 users），逐行扫描它；再拿每行的关联值（如 id）去另一张表（orders）里快速查找匹配行。这个“查找”过程，才真正依赖索引。
常见错误现象：EXPLAIN 显示被驱动表的 type 是 ALL 或 index，rows 值巨大，Extra 出现 Using join buffer (Block Nested Loop)——说明索引根本没被用上。
- 确保索引建在被驱动表的 ON 字段上，例如
orders.user_id，而不是只建在users.id（主键通常已有索引，但外键字段常被忽略） - 复合条件如
ON o.user_id = u.id AND o.status = 'paid'，优先建联合索引(user_id, status)，而非单列索引 - 索引字段类型必须严格一致：
INT和BIGINT、VARCHAR(50)和VARCHAR(100)若字符集或排序规则不同（如utf8mb4_0900_as_csvsutf8mb4_general_ci），索引会失效
为什么 LEFT JOIN 的右表索引也重要？
LEFT JOIN 保留左表全部记录，右表无匹配就填 NULL。表面看右表“可有可无”，但数据库仍需对每一行左表数据，在右表中做一次“是否存在匹配”的判断——这一步，照样走索引查找。没索引？就是全表扫一遍右表 × 左表行数。
使用场景：查所有用户及其订单数（含零单用户）：SELECT u.name, COUNT(o.id) FROM users u LEFT JOIN orders o ON u.id = o.user_id GROUP BY u.id
-
orders.user_id必须有索引，否则COUNT会退化为对每个用户都扫全表orders - 若右表该字段 NULL 值过多（比如 95% 订单记录缺失
user_id），MySQL 优化器可能放弃走索引——这时可考虑业务层清洗或加WHERE o.user_id IS NOT NULL显式过滤（但注意是否影响语义） - 避免在 ON 中混写状态过滤，如
ON u.id = o.user_id AND o.deleted = 0；应拆到WHERE或建联合索引(user_id, deleted)
覆盖索引能让 JOIN 更省 IO
如果被驱动表只需返回几个字段，而这些字段连同 JOIN 条件字段，都能被一个索引“包圆”，MySQL 就不用回主键索引捞整行数据——这就是覆盖索引的价值。
例如：SELECT u.name, o.amount FROM users u INNER JOIN orders o ON u.id = o.user_id，若 orders 表建了索引 (user_id, amount)，且 users.name 能通过主键快速定位（users.id 是主键），那整个 JOIN 就能避免大量磁盘 I/O。
- 索引顺序很关键：JOIN 条件字段必须放最左，如
(user_id, amount)有效，(amount, user_id)无效 - 若还需
ORDER BY o.amount且想避免filesort，可扩展为(user_id, amount)——前提是user_id是等值查询 - 不要为了覆盖索引盲目堆字段；字段越多，索引体积越大，写入开销越高
驱动表选错，再好的索引也白搭
MySQL 默认按 FROM 和 JOIN 顺序推测驱动表，但统计信息不准时会误判。比如你写 FROM big_table JOIN small_table，优化器却把大表当驱动表，导致小表被反复扫描——哪怕小表的 JOIN 字段有索引，也救不了性能。
实操建议：
- 用
EXPLAIN看table列顺序和各表的rows预估，确认哪张是驱动表 - 显式用
STRAIGHT_JOIN强制小表驱动：SELECT STRAIGHT_JOIN u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.status = 'active' - 在 JOIN 前先用
WHERE过滤驱动表，比如WHERE u.status = 'active'应紧贴FROM，比放到最后更早剪枝 - 多表 JOIN 时，中间表（如
order_items）最容易被忽略索引，务必逐个检查其 ON 字段
最常被忽略的一点：索引本身不能解决数据倾斜问题。比如某个 user_id = 1 对应 50 万条订单，即使有索引，单次查找仍要遍历大量索引页——这时候得结合分区、归档或应用层分页来缓解。
