using temporary和using filesort是多表join慢的最直接信号，表明mysql正使用磁盘临时表聚合或对外部大量数据排序，极耗io和cpu；常见于group by/order by未走索引、多表join后排序字段不在驱动表、select distinct配合大表关联等场景。
看执行计划里有没有 Using temporary 和 Using filesort
这两个 Extra 值是多表 JOIN 慢的最直接信号。一旦出现，说明 MySQL 正在用磁盘临时表做中间结果聚合，或者被迫对大量数据做外部排序——这两种操作都极耗 IO 和 CPU。
常见触发场景包括：
• GROUP BY 或 ORDER BY 字段没走索引，且结果集较大
• 多表 JOIN 后再 ORDER BY，而排序字段不在驱动表上
• SELECT DISTINCT 配合多个大表关联
- 别只盯着
type=ALL，有时候所有表都走了索引，但最后一步排序/去重把性能拖垮了 -
Using filesort出现在EXPLAIN的最后一行，不代表只排一次序——如果驱动表返回 10 万行，被驱动表每行都要参与排序，实际排序量可能是百万级
确认驱动表是不是最小过滤结果集
MySQL 的 JOIN 是嵌套循环（Nested Loop），外层表（驱动表）决定整体扫描基数。如果选错了驱动表，比如让一个 500 万行的用户表去驱动一个 10 万行的订单表，即使两个表都有索引，最终也要循环 500 万次去查订单表。
判断依据不是表大小，而是 WHERE 条件能过滤出多少行：
- 用
EXPLAIN看rows列：数值最小的那张表，才适合作为驱动表 - 如果某张表有高选择性条件（比如
create_time > '2026-09-01'），优先让它当驱动表 - 避免在被驱动表的 ON 条件里写函数，例如
ON DATE(o.create_time) = u.reg_date，这会让索引失效，导致该表退化为全表扫描
检查 JOIN 字段有没有双向索引
两张表关联，光有一方有索引不够。比如 orders.user_id 有索引，但 users.id 是主键所以自带索引——看起来没问题。但如果 users 是被驱动表，而你写的 JOIN users u ON o.user_id = u.id，MySQL 实际查 users 表时，是拿 o.user_id 的每个值去查 users.id，这时依赖的是 users.id 的主键索引，没问题；但反过来，如果 JOIN 顺序调换，users 变成驱动表，它要按 u.id 去查 orders.user_id，那就必须确保 orders.user_id 上有索引。
- 原则：被驱动表的 JOIN 字段必须有索引，否则就是全表扫描
- 外键列不等于有索引。很多团队建了外键约束，却忘了手动加索引，这是线上高频踩坑点
- 复合索引要注意字段顺序：如果
WHERE用a = ? AND b = ?，而JOIN用b = ?，那么(a,b)索引对 JOIN 无效，得单独建(b)或调整为(b,a)
警惕隐式类型转换导致的索引失效
当 JOIN 字段类型不一致时，MySQL 会自动做类型转换，而这个过程大概率让索引失效。典型例子：
• orders.user_id 是 BIGINT，users.id 是 VARCHAR
• 或者 orders.status 是 TINYINT，但代码里传参是字符串 "1"
这种情况下，EXPLAIN 里 key 会是 NULL，type 回退到 ALL，但你很难从 SQL 文本里一眼看出问题。
- 用
SHOW WARNINGS查看优化器警告，常会看到类似 “Cannot use ref access on index … due to type or collation conversion” - 检查
information_schema.COLUMNS确认关联字段类型是否完全一致（包括字符集、是否允许 NULL） - 应用层传参时，别用字符串拼接 ID，用参数化查询并确保类型匹配
EXPLAIN ANALYZE（PostgreSQL）或 EXPLAIN FORMAT=JSON（MySQL 8.0+）比反复改 SQL 更有效。
