join字段无索引必然全表扫描，on条件任一侧缺失索引即触发type=all；需确保关联字段均有索引、外键建索引、复合索引按on顺序排列、字符集一致；驱动表选错或函数滥用也会导致索引失效。
JOIN字段没索引，必然全表扫描
只要ON条件里用到的字段（比如a.user_id = b.id中的user_id和id）任意一侧缺失索引，MySQL就只能扫全表匹配。这不是“可能慢”，而是“一定慢”——尤其当大表参与时，type=ALL会直接出现在EXPLAIN结果里。
实操建议：
- 检查两张表的关联字段是否都有索引：
SHOW INDEX FROM users、SHOW INDEX FROM orders - 外键字段必须建索引，哪怕只是
ALTER TABLE orders ADD INDEX idx_user_id (user_id) - 复合索引要按
ON条件顺序排列，例如ON o.user_id = u.id AND o.status = 'paid'，推荐建KEY idx_user_status (user_id, status)，而非反过来 - 字符串字段JOIN时，确认
CHARSET和COLLATION完全一致，否则隐式转换会让索引失效
EXPLAIN里看到type=ALL，说明驱动表选错了
type=ALL不只代表“没索引”，也可能是优化器误判了驱动表——它把大表当成了外层循环，导致反复扫描小表。这时候rows值会异常高，key列为空或不是预期索引。
实操建议：
- 先用
WHERE缩小左表结果集，再JOIN：SELECT * FROM (SELECT * FROM users WHERE status = 'active') u JOIN orders o ON u.id = o.user_id - 手动指定驱动顺序：在确定小表是
users时，加STRAIGHT_JOIN强制执行顺序：SELECT * FROM users STRAIGHT_JOIN orders ON users.id = orders.user_id - 避免
LEFT JOIN大表后不做WHERE过滤，这会让左表全量参与嵌套循环 - 定期运行
ANALYZE TABLE users, orders，让统计信息准确，帮优化器做对选择
JOIN条件里写了函数，索引当场失效
哪怕字段本身有索引，只要在ON或WHERE里对它用了函数或表达式，比如ON UPPER(a.name) = UPPER(b.name)或ON DATE(o.create_time) = '2026-06-18'，索引就完全失效——MySQL无法用B+树直接定位，只能扫全表。
实操建议：
- 把函数挪到等号右边：
WHERE o.create_time >= '2026-06-18' AND o.create_time - 字符串比对统一转存为小写字段并建索引，而不是每次
UPPER()计算 - 避免
OR连接不同字段（如ON a.id = b.a_id OR a.code = b.code），其中一个没索引就会触发全表扫描；改用UNION拆成两个独立查询 - LIKE模糊查如果必须前导%（
LIKE '%abc'），别指望B+树索引，考虑全文索引或应用层处理
SELECT * + 多表JOIN，回表开销压垮性能
表面看是JOIN慢，实际常因SELECT *导致大量字段被读取、传输、拼接，尤其当涉及大文本字段或JSON列时。更隐蔽的问题是：没覆盖索引，就得反复回表取数据，I/O翻倍。
实操建议：
- 只查真正需要的字段：
SELECT u.name, o.amount, o.status，而不是SELECT * - 为高频查询建覆盖索引，把
SELECT字段和JOIN字段一起包进去：ALTER TABLE orders ADD INDEX idx_user_amount_status (user_id, amount, status) - 三张以上大表JOIN时，优先考虑拆成两段：先查出ID列表，再用
IN二次查询，避免中间结果集爆炸 - 注意
JOIN字段类型必须严格一致——INT对BIGINT、VARCHAR(32)对VARCHAR(64)都可能导致隐式转换和索引跳过
真正卡住的地方往往不是“要不要加索引”，而是索引建在哪、怎么用、以及MySQL到底有没有真的用上它。每条EXPLAIN输出里的type、key、rows和Extra，都在告诉你它此刻的真实行为——不看这个，调优就是盲人摸象。
