LEFT JOIN右表ON字段无索引会导致全表扫描，是常见性能杀手；需在右表ON字段建索引，确保字段类型、字符集一致，并避免子查询作右表，COUNT(*)应改用EXISTS优化。
LEFT JOIN右表ON字段没索引，直接全表扫描
这是最常见也最容易被忽略的性能杀手。MySQL执行LEFT JOIN时，左表所有行都会保留，但右表每条记录都要按ON条件去匹配——如果右表的关联字段（比如user_id）没有索引，MySQL只能对右表逐行扫描，EXPLAIN里会看到type: ALL和Extra: Using join buffer (Block Nested Loop)。哪怕右表只有几千行，嵌套循环的开销也会指数级上升。
- 先用
EXPLAIN确认问题：重点看右表对应的key是否为NULL、rows是否远大于实际匹配数、type是不是ALL或index - 索引必须建在右表的
ON字段上，不是左表——左表驱动，右表被查，索引建错方向等于白建 - 单列索引通常够用；若右表还有
WHERE过滤，可考虑联合索引把ON字段放最左
字段类型或字符集不一致，索引形同虚设
即使右表ON字段有索引，只要和左表对应字段的类型、字符集或排序规则不一致，MySQL就无法使用该索引。典型场景是左表user_id是INT，右表却是VARCHAR；或两张表一个用utf8mb4，一个用utf8。此时EXPLAIN里key列仍显示索引名，但rows暴增、filtered掉到100%，本质还是全表扫描。
- 检查字段类型：
SHOW CREATE TABLE table_name对比左右表关联字段的DATA_TYPE、COLLATION_NAME - 修复优先级：先统一类型（如都转成
INT或都VARCHAR(32)），再统一字符集和校对规则 - ALTER操作后务必重新
EXPLAIN验证，别只看索引是否存在
右表是子查询，索引根本用不上
当LEFT JOIN的右表写成子查询（比如(SELECT ... FROM large_table WHERE ...)），MySQL通常会物化这个结果集，生成临时表。这个临时表默认无索引，后续匹配全靠遍历——无论原表有没有索引，都白搭。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 优先把子查询拆出来，建临时表并显式加索引：
CREATE TEMPORARY TABLE tmp_r AS SELECT ...; ALTER TABLE tmp_r ADD INDEX idx_on_field (field); - 更彻底的方案是重写SQL：用
EXISTS替代LEFT JOIN子查询（尤其只关心是否存在时），或把子查询逻辑下推到JOIN条件中 - 避免多层嵌套子查询，MySQL 5.7+对派生表优化有限，容易触发
Using temporary
COUNT(*)配合LEFT JOIN特别慢，别硬扛
SELECT COUNT(*) FROM a LEFT JOIN b ON a.id = b.a_id这类语句，表面只计数，实际MySQL仍要构造完整连接结果集再统计——右表没索引时，代价比带SELECT *还高。因为不需要字段值，却被迫扫描全部组合。
- 如果业务只要“左表有多少条在右表有匹配”，改用
SELECT COUNT(*) FROM a WHERE EXISTS (SELECT 1 FROM b WHERE b.a_id = a.id)，能跳过NULL补全和冗余扫描 - 如果真要统计
LEFT JOIN后的总行数，且右表数据稀疏，可先COUNT左表，再减去NOT EXISTS的差集数量，分步降低压力 - 切忌在
LEFT JOIN后加WHERE过滤右表字段（如WHERE b.status = 'ok'），这会让语义退化为INNER JOIN，但执行计划可能更差
真正卡住的地方往往不是“要不要加索引”，而是加在哪张表、哪个字段、什么类型上——连EXPLAIN里key列显示有索引，都可能是假象。每次改完记得跑一遍EXPLAIN FORMAT=TRADITIONAL，盯着rows和filtered看，数字不对劲，说明还没修到位。
