连接字段必须单独建索引，不能依赖联合索引前缀；left join右表连接字段无索引会导致n×m级扫描；混合where+join时应按过滤强度→连接字段→查询列设计覆盖索引；优化器自动选驱动表，需依据explain的rows和filtered判断而非人为指定。
连接字段必须单独建索引
MySQL 在执行 JOIN 时，如果连接条件（如 ON t1.id = t2.t1_id）中的字段没有索引，会触发全表扫描，性能断崖式下降。即使被连接表只有几万行，没索引也可能让查询从毫秒级拖到秒级。
关键点：连接字段的索引必须是**独立存在**的，不能只靠联合索引的前缀“顺便覆盖”。例如，t2(t1_id, status) 这个联合索引，在 ON t2.t1_id = t1.id 场景下能用，但如果查询还带 WHERE t2.status = 'active'，且顺序写成 ON t2.t1_id = t1.id WHERE t2.status = 'active'，优化器可能选错索引或无法高效定位。
- 为每个
JOIN条件中的字段单独建索引，比如ALTER TABLE t2 ADD INDEX idx_t1_id (t1_id); - 若该字段常和其它列一起过滤，再补一个联合索引，但别指望它替代单列索引
-
EXPLAIN中看type列：要是ALL或index（非覆盖），基本说明连接字段没走索引
WHERE + JOIN 混合场景优先建覆盖索引
当查询既有连接又有过滤（如 JOIN ... ON ... WHERE t1.state = 'done' AND t2.created_at > '2024-01-01'），单列索引容易失效。MySQL 通常只能用上一个索引，其余条件退化为回表或临时表处理。
此时应按「过滤强度高 → 连接字段 → 查询需要的列」顺序设计联合索引。例如，t1(state, id) 可让 WHERE state = 'done' 快速定位，再通过 id 高效驱动连接；若 SELECT 还要 t1.name，就扩展为 t1(state, id, name)，避免回主键查。
- 过滤条件列放最左（尤其是等值查询，范围查询如
>要放右） - 连接字段紧随其后（确保驱动表结果集小，被驱动表能用索引快速匹配）
- SELECT 中的非主键列可加在最后，构成覆盖索引，减少
Using filesort和Using temporary
小表驱动大表不是硬规则，得看实际执行计划
老说法“用小表做驱动表”在 MySQL 8.0+ 并不总成立。优化器会基于统计信息估算代价，自动选择驱动顺序。强行用 STRAIGHT_JOIN 可能适得其反——比如你认为 A 表小，但它有大量 NULL 值或数据倾斜，真实扫描行数远超预期。
真正该盯的是 EXPLAIN 输出里的 rows 和 filtered：前者是预估扫描行数，后者是条件过滤后剩余比例。如果某张表 rows=100000 但 filtered=0.1，实际只留 100 行，它反而更适合作为驱动表。
- 别手动假设大小，用
SELECT COUNT(*)和SHOW TABLE STATUS看真实行数与平均行长度 - 对连接字段执行
ANALYZE TABLE，确保统计信息不过期 - 遇到优化器选错顺序，优先检查索引是否缺失或统计不准，而不是直接加
STRAIGHT_JOIN
LEFT JOIN 的右表字段索引容易被忽略
很多人给左表加完索引就以为万事大吉，但 LEFT JOIN 中右表的连接字段如果没索引，会导致左表每行都去右表全扫一遍。哪怕右表只有 1 万行，左表 1000 行，最坏就是 1000 × 10000 = 1000 万次 I/O。
更隐蔽的问题是：右表如果有 WHERE 条件（如 LEFT JOIN t2 ON t1.id = t2.t1_id WHERE t2.status IS NOT NULL），这实际上把 LEFT JOIN 变成了 INNER JOIN 语义，但优化器未必能重写，仍可能先全量关联再过滤，此时右表索引缺失代价更大。
- 只要出现在
ON或WHERE中的右表字段，一律加索引 - 特别注意
IS NULL/IS NOT NULL条件，它们无法使用普通 B+ 树索引的最左前缀，需确认索引是否生效（EXPLAIN中key是否为空） - 用
FORCE INDEX临时验证右表索引效果，但上线前务必回归到自然执行计划
SELECT * 和 SELECT t1.id, t2.name 所需的最优索引可能完全不同。别依赖通用建议，每次改查询都该重新跑 EXPLAIN 看 key_len 和 Extra。 
