join 的 on 条件列必须有索引，否则被驱动表将全表扫描；on 两侧字段类型须严格一致，复合索引需符合最左前缀原则，left join 右表索引同样关键，驱动表选择影响性能，避免函数或表达式破坏索引，覆盖索引仅对被驱动表有效。
JOIN 的 ON 条件列必须有索引，否则就是全表扫描
MySQL 在执行 JOIN 时，不会自动为连接列建索引。如果 ON a.id = b.a_id 中的 a.id 或 b.a_id 没索引，驱动表每扫一行，被驱动表就得全表扫一次——数据量一过万，查询直接卡住。
实操建议：
- 先用
EXPLAIN看type字段：出现ALL就代表某边在全表扫描 -
ON两侧字段类型要严格一致（比如都是INT UNSIGNED），隐式转换会让索引失效 - 复合索引要注意最左前缀：如果
ON b.category_id = ? AND b.status = ?，那索引得是(category_id, status)，反过来没用
LEFT JOIN 右表没匹配时，索引依然要建在右表连接列上
很多人以为 LEFT JOIN 左表是主表，右表索引不重要。错。MySQL 仍需根据左表每行的值，在右表快速定位匹配行；没索引，右表就重复全表扫描。
常见错误现象：
- 左表 10 万行，右表 5 万行，没索引时执行时间从 200ms 涨到 12s
-
EXPLAIN显示右表type=ALL，rows列等于右表总行数 - 加了
WHERE b.id IS NULL这种反向条件后更慢——因为 MySQL 先硬扫右表再过滤
多表 JOIN 时，驱动表选择影响索引是否生效
MySQL 默认按 FROM 后顺序选驱动表（小结果集优先），但优化器可能误判。一旦选错，即使所有连接列都有索引，也会因驱动表太大导致被驱动表反复索引查找，I/O 暴增。
判断与干预方法：
- 用
EXPLAIN FORMAT=tree（8.0+）看实际驱动顺序，比传统EXPLAIN更准 - 强制指定驱动表：用
STRAIGHT_JOIN，但仅限确认优化器出错时临时用，别写死在业务 SQL 里 - 避免在 JOIN 条件里用函数或表达式，比如
ON YEAR(b.create_time) = YEAR(a.time)—— 索引直接失效
覆盖索引能减少回表，但只对被驱动表有效
如果被驱动表的 SELECT 字段全在某个索引里（比如 SELECT b.name, b.code FROM a JOIN b ON a.id = b.a_id，而 b 有联合索引 (a_id, name, code)），MySQL 就不用回主键索引查数据，速度能提 30%~50%。
注意点：
- 覆盖索引对驱动表无效——驱动表本身就要走主键或聚簇索引取全行
- 别为了覆盖索引把太多字段塞进联合索引，写放大和内存占用会上升
-
TEXT/BLOB类型不能包含在索引中，相关字段无法参与覆盖
EXPLAIN 里却看不到它被用上。
