WHERE 条件字段没加索引，JOIN 就白搭
MySQL 的
JOIN本身不直接走索引，真正决定性能的是驱动表（左表）的
WHERE条件是否能用上索引，以及被驱动表（右表）的
ON关联字段是否有索引。如果
WHERE过滤后驱动表仍返回几万行，再怎么优化
ON字段也没用。
实操建议：
先确认驱动表的过滤条件字段（比如user.status = 'active'）是否在
user表上有索引 —— 单列索引或联合索引的最左前缀都行 被驱动表的关联字段（如
orders.user_id）必须有索引，否则会触发
ALL扫描，Explain 里看到
type: ALL就是它 避免在
ON或
WHERE中对字段做函数操作，例如
ON DATE(o.create_time) = '2024-01-01'会让
create_time索引失效
多表 JOIN 时驱动表选错，性能断崖式下跌
MySQL 默认按 FROM 后顺序选择驱动表（左深树），但优化器可能因统计信息不准而选错。比如
SELECT ... FROM large_table JOIN small_table ON ...，若
large_table没有效过滤条件，就会拿它当驱动表，导致对
small_table做几百万次嵌套循环查找。
实操建议：
用EXPLAIN FORMAT=TRADITIONAL查看
table列顺序和
rows预估，重点关注驱动表的
rows是否远超预期 强制指定驱动表：用
STRAIGHT_JOIN（仅限 INNER JOIN），写成
SELECT STRAIGHT_JOIN ... FROM small_table JOIN large_table ON ...给小结果集的表加
FORCE INDEX，例如
FROM orders FORCE INDEX (idx_user_status) JOIN users ON ...
ON 和 WHERE 混用导致索引失效或语义错误
LEFT JOIN 中，把本该写在
WHERE的过滤条件错放
ON子句，不仅可能让索引无法生效，还会改变结果逻辑。比如
LEFT JOIN orders ON u.id = o.user_id AND o.status = 'paid'，这条
o.status = 'paid'是关联条件的一部分，不是过滤条件 —— 它会让
orders表只匹配已支付订单，但依然保留用户；而写成
WHERE o.status = 'paid'就会把没订单或订单未支付的用户全过滤掉。
实操建议：
ON只放关联逻辑（
u.id = o.user_id）和被驱动表的「窄化关联范围」条件（如
o.deleted = 0），前提是该字段有索引且能减少匹配行数
WHERE放最终结果过滤，尤其是驱动表字段的条件必须在这里写，否则 LEFT JOIN 可能退化为 INNER JOIN 如果被驱动表的
ON条件含非等值判断（如
o.amount > 100），MySQL 通常无法用索引加速关联，应尽量避免
联合索引顺序不对，覆盖不了 JOIN + WHERE 组合场景
比如查询
SELECT u.name, o.amount FROM users u JOIN orders o ON u.id = o.user_id WHERE u.city = 'Shanghai' AND u.status = 'active'，如果只在
users表建了
(status, city)索引，那
city字段就用不上最左前缀，导致全表扫描。
实操建议：
联合索引顺序按「过滤性高 + 出现在 WHERE 的频率高」排序，例如city区分度通常高于
status，优先放前面：
(city, status)如果查询还带
ORDER BY u.created_at，可扩展为
(city, status, created_at)，实现“索引覆盖”，避免回表 对被驱动表，
ON字段必须是联合索引的第一列，例如
orders(user_id, status)能用于
ON o.user_id = u.id，但
(status, user_id)就不行
EXPLAIN SELECT u.name, o.amount FROM users u STRAIGHT_JOIN orders o ON u.id = o.user_id WHERE u.city = 'Shanghai' AND u.status = 'active' AND o.status = 'paid';
复杂点往往不在语法，而在你没意识到驱动表的
rows预估偏差有多大，或者
EXPLAIN里那个
key_len值已经暴露了索引只用了一半。别急着改 SQL，先看执行计划里哪一行在扫全表。
