explain显示rows远超预期，主因是mysql选错驱动表或过滤条件未下推；应优先在where中对大表加条件、调整join顺序、避免隐式转换及错误放置left join的where条件。
为什么EXPLAIN显示rows远超预期？
这不是索引没建，而是MySQL选错了驱动表或过滤条件没下推。比如orders表有1000万行，users表有50万行，但SQL写成 SELECT * FROM orders o LEFT JOIN users u ON o.user_id = u.id，优化器可能仍以orders为驱动表——哪怕加了user_id索引，也要先扫完1000万行再去找匹配的用户。
关键判断点：EXPLAIN里rows列数值是否接近某张表的总行数？如果是，说明那张表被当成了驱动表，且没被有效过滤。
- 优先在
WHERE里对大表加条件（比如o.created_at >= '2025-01-01'），而不是等JOIN完再筛 - 把小结果集表放在
FROM后第一个位置，尤其对INNER JOIN，优化器更倾向用它驱动 - 如果必须用大表作主表，考虑加
STRAIGHT_JOIN强制小表驱动，但得配合EXPLAIN验证效果
关联字段有索引，为什么type还是ALL？
type=ALL意味着全表扫描，即使字段上有索引，也可能因为以下原因失效：
- 连接条件用了函数或表达式，比如
ON YEAR(o.order_date) = YEAR(u.register_year)→ 改成范围条件：o.order_date BETWEEN '2025-01-01' AND '2025-12-31' - 复合索引顺序不匹配，例如在
orders上建了(status, user_id)，但查询只用了user_id→ 单独为user_id建索引，或调整复合索引为(user_id, status) - 字段类型隐式转换，比如
orders.user_id是INT，users.id是BIGINT→ 两边类型必须严格一致，否则索引失效 -
LEFT JOIN右表字段出现在WHERE里（如WHERE u.status = 'active'），会把LEFT JOIN转成INNER JOIN逻辑，但优化器可能没重写执行计划 → 把这个条件移到ON子句里
如何避免Using temporary和Using filesort？
这两个Extra值出现，通常是因为排序或分组操作无法利用索引，被迫创建临时表或磁盘排序。
- 确保
ORDER BY字段属于驱动表，且是索引最左前缀。例如驱动表是users，想按u.name排序，那就建索引(name, id)（id用于回表） - 避免在
SELECT里用*，尤其当涉及TEXT或BLOB字段时，容易触发Using temporary→ 明确列出需要字段，必要时加覆盖索引 - 如果
GROUP BY字段不在驱动表，或者跨表聚合，大概率会生成临时表 → 拆成子查询，先在单表内聚合，再JOIN -
LIMIT要配合ORDER BY使用，否则优化器可能放弃索引排序 →ORDER BY created_at DESC LIMIT 20比ORDER BY created_at LIMIT 20更容易走索引
哪些JOIN写法实际更慢？
不是语法越“标准”就越高效。有些看似合理的写法，执行代价反而更高：
-
LEFT JOIN+ 右表WHERE非空条件：本质变成INNER JOIN，但优化器可能仍保留左表全扫描逻辑 → 直接改用INNER JOIN - 多个
LEFT JOIN嵌套，尤其右表数据量大：每层都可能放大中间结果集 → 先用子查询或CTE预过滤右表，比如(SELECT id, name FROM users WHERE status = 'active') u - 用
IN (subquery)替代JOIN：子查询若未走索引，可能比JOIN还慢 → 优先用JOIN，且确保子查询结果集小 - 在应用层拼
IN列表（如WHERE id IN (1,2,3,...1000)）：参数过多导致执行计划失效或缓存命中率低 → 改用临时表或批量分页处理
真正影响性能的，从来不是JOIN本身，而是扫描行数、临时表和排序这三件事是否可控。只要EXPLAIN里rows没爆炸，key有命中，Extra没出现高成本标识，就还没到必须拆查询的地步。
