为什么加了索引，JOIN 还很慢？
常见错觉是“只要给 JOIN 字段加索引就万事大吉”，但实际慢往往因为：
ON条件字段类型不一致、隐式类型转换、索引未被选中，或者驱动表选错了。比如
user.id是
BIGINT，而
order.user_id是
VARCHAR，MySQL 会放弃使用
user_id索引，转为全表扫描
order表。
实操建议：
用EXPLAIN看
type是否为
ref或
eq_ref；若为
ALL或
index，说明没走索引 检查
ON两侧字段的
COLLATION和数据类型是否完全一致（用
SHOW CREATE TABLE对比） 避免在
ON或
WHERE中对关联字段做函数操作，例如
ON DATE(order.time) = DATE(user.created_at)会失效索引
怎么选驱动表？小表一定在左边吗？
MySQL 的嵌套循环 JOIN 中，驱动表（外层表）决定扫描次数。传统说法“小表驱动大表”只在无索引或索引失效时成立；有合适索引时，**驱动表应选过滤后结果集最小的那个**，而非物理行数最少的表。
实操建议：
先看单表加WHERE条件后的预估行数（
EXPLAIN的
rows字段），选
rows最小的作为驱动表 用
STRAIGHT_JOIN强制连接顺序（仅当优化器选错且你确认更优时），例如：
SELECT STRAIGHT_JOIN ... FROM user u JOIN order o ON u.id = o.user_id注意：如果大表上有高选择性索引（如
status = 'paid'只返回 0.1% 行），它反而可能更适合当驱动表
临时表和排序导致 JOIN 巨慢？
当
JOIN后需要
GROUP BY、
ORDER BY或
SELECT *且无法走覆盖索引时，MySQL 可能创建内部临时表（
Using temporary）并触发文件排序（
Using filesort），I/O 开销陡增。
实操建议：
用EXPLAIN观察
Extra列是否含
Using temporary或
Using filesort把
ORDER BY字段加入复合索引末尾，例如
INDEX(user_id, created_at)支持
JOIN ... ORDER BY created_at避免
SELECT *，只查真正需要的字段；尤其别让大文本字段（
TEXT、
MEDIUMTEXT）参与 JOIN 结果集 调大
tmp_table_size和
max_heap_table_size（需两者都设），让临时表尽量在内存中完成
什么时候该拆 JOIN，改用应用层关联？
当 JOIN 涉及 3 张以上表、或某张表数据量极大（千万级）、或存在
OR条件 /
LIKE '%xxx'等无法利用索引的场景时，数据库优化空间已很有限。此时硬扛 JOIN，不如在应用层分步查+内存关联。
实操建议：
第一步查主表（如user），拿到 ID 列表（控制数量，如
LIMIT 100） 第二步用
IN批量查从表（如
SELECT * FROM order WHERE user_id IN (1,2,3...)），注意
IN参数不宜超过 1000 个，可分批次 在代码里用哈希表做关联（如 Python 的
dict，Go 的
map），比 MySQL 多层嵌套更可控 警惕 N+1：确保是“1 次主查 + 1 次从查”，而不是循环里查从表
真正难的不是写 JOIN，而是判断它该不该由数据库执行——很多线上慢查询，根子不在 SQL 写得不好，而在业务场景本身就不适合单次多表 JOIN。
