JOIN字段无索引必然导致type=ALL全表扫描，需检查并为关联字段手动添加索引，确保字符集与排序规则一致，复合索引须按ON条件顺序排列，避免函数或表达式使索引失效。
JOIN字段没索引，type=ALL是铁律
只要ON条件里任一侧字段没索引，MySQL就必然走全表扫描，EXPLAIN里type=ALL不是警告，是确诊书。这不是“可能慢”，而是“一定慢”——尤其当大表参与时，rows值会爆炸式增长。
实操建议：
- 用
SHOW INDEX FROM table_name逐个检查关联字段是否建索引，别只看主键 -
orders.user_id这种外键字段，即使业务上没显式定义外键约束，也必须手动加索引：ALTER TABLE orders ADD INDEX idx_user_id (user_id) - 字符串字段JOIN时，用
SHOW CREATE TABLE确认两边的CHARSET和COLLATION完全一致，否则隐式转换会让索引失效
复合索引顺序必须匹配ON条件顺序
比如ON o.user_id = u.id AND o.status = 'paid'，索引建(status, user_id)就无效——B+树按最左前缀匹配，user_id被跳过，只能回退到type=range甚至ALL。
实操建议：
- 把等值条件字段放前面，范围条件（如
>、BETWEEN）放后面：推荐KEY idx_user_status (user_id, status) - 如果查询还带
SELECT u.name, o.amount，可升级为覆盖索引：KEY idx_user_status_cover (user_id, status, name, amount)，避免回表 - 不要为每个字段单独建单列索引，
user_id和status各自有索引 ≠ 联合查询能用上
函数或表达式一写，索引当场作废
ON UPPER(a.name) = UPPER(b.name)或WHERE DATE(o.create_time) = '2026-06-18'这类写法，会让索引彻底失效。MySQL无法用B+树直接定位函数结果，只能扫全表。
实操建议：
- 把函数挪到等号右边：
WHERE o.create_time >= '2026-06-18' AND o.create_time - 若必须大小写不敏感比较，提前在字段上建函数索引（MySQL 8.0+）：
CREATE INDEX idx_name_lower ON users ((LOWER(name))) - 时间字段避免用
DATE()，改用范围查询；字符字段避免LIKE '%abc'，这类也无法走索引
驱动表选错，索引再好也白搭
EXPLAIN里看到key列为空或不是预期索引，但type却是ref，大概率是优化器误判了驱动表——它把大表当成了外层循环，导致小表被反复扫描。
实操建议：
- 先用
WHERE缩小左表结果集：SELECT * FROM (SELECT * FROM users WHERE status = 'active') u JOIN orders o ON u.id = o.user_id - 确定小表是
users时，用STRAIGHT_JOIN强制顺序：SELECT * FROM users STRAIGHT_JOIN orders ON users.id = orders.user_id - 定期执行
ANALYZE TABLE users, orders，让统计信息准确，帮优化器做对选择
真正卡住性能的往往不是SQL写法本身，而是索引存在但没被用上——要么顺序不对，要么被函数拦腰截断，要么驱动表反向放大了扫描量。盯着EXPLAIN的type和key两列，比调参更管用。
