连接字段必须单独建索引
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。
