驱动表选错，索引再好也白搭：优化器依据explain中rows（where过滤后预估行数）选驱动表，非总行数；left join左表强制驱动，inner join由优化器按成本选择；被驱动表on字段必须有匹配顺序的索引，且字段类型、字符集、排序规则须严格一致。
驱动表选错，索引再好也白搭
MySQL优化器选驱动表，看的不是表总行数，而是EXPLAIN输出中每张表的rows列——即WHERE过滤后预估返回的行数。哪怕users有100万行，只要WHERE status = 'active'能筛出200行，它就很可能当驱动表；反之，orders只有50万行但没WHERE条件，rows显示50万，它反而可能被选为驱动表，导致右表全表扫描几十万次。
常见踩坑点：
- LEFT JOIN左表强制驱动，哪怕
rows是80万也得硬上，右表索引再全也没法避免大量匹配 - INNER JOIN下别信书写顺序，优化器可能因统计信息过期（
ANALYZE TABLE没跑）而误判，rows不准时先执行ANALYZE TABLE t1, t2 - 用
STRAIGHT_JOIN前务必确认你比优化器更清楚数据分布，否则把100行驱动强行改成10万行驱动，性能直接跌穿底
被驱动表ON字段必须有索引，且顺序不能错
只要某张表在ON子句里是“被查”的一方（比如LEFT JOIN orders o ON u.id = o.user_id中的orders.user_id），它的关联字段就必须有索引。主键、唯一索引、普通索引都行，但不能没有——没索引=每次驱动行都要扫一遍全表。
实操要点：
- 复合
ON条件如ON t1.a = t2.x AND t1.b = t2.y，必须建INDEX(x, y)，顺序严格匹配ON中出现顺序；INDEX(y, x)或INDEX(a, b, c)对t2.y无效 - LEFT JOIN右表、RIGHT JOIN左表最容易漏索引，务必逐个检查
SHOW INDEX FROM table_name - 外键约束不自动建索引，必须手动加；即使建了，也要确认
DESCRIBE里字段类型完全一致（INT vs BIGINT、VARCHAR(50) vs VARCHAR(100)都会触发隐式转换）
联合索引字段顺序：JOIN字段必须放WHERE字段前面
MySQL执行逻辑是：拿驱动表一行 → 用ON条件去被驱动表找匹配行 → 再对匹配行做WHERE过滤。所以索引必须优先支持ON查找，再覆盖WHERE过滤。
例如：JOIN users u ON o.user_id = u.id WHERE u.status = 'active'，索引必须是INDEX(id, status)，而不是INDEX(status, id)。后者会让ON o.user_id = u.id完全无法走索引定位。
例外情况：
- 如果
WHERE字段区分度极高（比如status只有3个值，但id是外键重复率高），可考虑改写SQL：先SELECT id FROM users WHERE status = 'active'生成临时结果，再JOIN，避免单索引两头兼顾 -
ON中混入非等值条件（如o.amount > 100）会直接让索引失效，这类场景应前置过滤或换算法
字符集、排序规则和隐式转换，比没索引还致命
字段类型或字符集不一致，MySQL会在运行时做隐式转换，导致被驱动表索引彻底失效。典型表现是EXPLAIN里type为ALL或index，key列为NULL，但字段明明建了索引。
必须核对的三项：
- 字段类型：用
DESCRIBE table_name对比两边Type列，确保都是INT或都是BIGINT，不能一边INT一边UNSIGNED INT - 字符集与排序规则：比如
utf8mb4_0900_as_cs和utf8mb4_general_ci混合比较，索引直接失效 - 函数/表达式：
ON DATE(o.create_time) = u.date_key或ON CAST(t1.id AS CHAR) = t2.ref_id都会让索引失效，改用范围条件或冗余字段替代
真正卡住性能的，往往不是“要不要加索引”，而是EXPLAIN里看着有索引、type却是ALL，却一直没去查字段类型和字符集是否咬合。
