复合索引在left join中未命中，最常见原因是右表连接字段未遵循最左前缀原则、字段类型或字符集不一致、数据量过小导致优化器放弃索引、where条件将外连接转为内连接并干扰索引选择。
LEFT JOIN 时复合索引未命中，最常见原因是连接字段没走最左前缀
MySQL 的 JOIN 操作本身不改变索引使用逻辑，但优化器会为被驱动表（即右表）选择访问路径。如果右表的连接条件只用了复合索引的非最左列，比如索引是 (motorcadeId, userId, isDelete)，而查询只写了 ON u.motorcadeId = a.motorcadeId，那没问题；但若后续 WHERE 或 ON 中又加了 u.isDelete = 0 却没带上 userId，就可能让优化器放弃该索引——因为 isDelete 不是最左列，无法跳过 userId 直接定位。
常见错误现象：
-
EXPLAIN显示右表的key为空，type是ALL或index - 单独用
motorcadeId查询能走索引，一 JOIN 就失效 - 明明建了
(a,b,c)索引，但ON t1.x = t2.a AND t2.c = 1就不生效
实操建议：
- 检查
JOIN条件中右表字段是否严格按复合索引最左列开始连续出现（例如索引(A,B,C)，则ON ... = A✅，ON ... = A AND B = ?✅，ON ... = B❌） - 用
EXPLAIN FORMAT=TRADITIONAL查看possible_keys和key，确认优化器是否考虑过你的索引 - 若必须跳过中间列，考虑补一个更短的索引，比如已有
(motorcadeId, userId, isDelete)，再加(motorcadeId, isDelete)
被驱动表字段类型不一致，隐式转换直接废掉索引
LEFT JOIN 中，如果左表字段是 INT，右表对应连接字段却是 VARCHAR，MySQL 会把右表字段转成数字做比较，导致无法走索引。这种隐式转换在 EXPLAIN 中通常表现为 type: ALL、Extra: Using where，且没有 key 值。
典型场景：
- 左表
alarm.motorcadeId是INT，右表user_motorcade.motorcadeId是VARCHAR - 两个表字符集或排序规则不同（如
utf8mb4_general_civsutf8mb4_unicode_ci） - 连接字段有空格或不可见字符，触发自动 trim/convert
实操建议：
- 用
SHOW CREATE TABLE对比左右表连接字段的完整定义，包括类型、长度、是否 NULL、字符集、排序规则 - 统一类型优先于加索引：用
ALTER TABLE ... MODIFY COLUMN把两边都改成INT UNSIGNED或都改成BIGINT - 避免用函数包装连接字段，比如
CAST(u.motorcadeId AS SIGNED)会强制走全表扫描
数据量太少，优化器主动放弃索引
MySQL 5.6+ 的优化器会估算成本。如果被驱动表只有几行数据（比如 dic_bid_type 表仅存 4 条记录），它认为全表扫描比走索引+回表更快，就会跳过索引。这不是 bug，是成本决策——EXPLAIN 中 key 为空，但 rows 很小，Extra 无警告，基本就是这个原因。
容易被忽略的点：
- 开发环境数据量远小于生产，测试时索引“失效”不代表线上也失效
-
ANALYZE TABLE可刷新统计信息，但对极小表影响有限 - 加数据不是万能解法：若业务上该表确实长期只有个位数记录，不如直接用内存缓存替代 JOIN
实操建议：
- 用
SELECT COUNT(*) FROM table_name确认真实行数，别信“应该有很多” - 临时加测试数据验证：
INSERT INTO dic_bid_type VALUES (5,'test'),(6,'test2');再EXPLAIN - 若确认是小表，考虑在应用层查出主表结果后，用 IN 批量查字典表，避免 JOIN
WHERE 条件污染了 JOIN 的索引选择
LEFT JOIN 的右表如果在 WHERE 中加了非 NULL 过滤条件，会把外连接转成内连接，同时可能让优化器重新评估索引。例如 LEFT JOIN sys_city_info b ON b.code = a.city_code WHERE b.name IS NOT NULL，此时 b 表实际变成内连接，但 WHERE 中的 b.name 并不在连接索引里，优化器可能干脆弃用原索引。
关键陷阱：
-
WHERE中对右表字段的非空判断、范围查询、函数调用，都会干扰索引选择 - 复合索引若没覆盖
WHERE字段，优化器可能选错索引或放弃索引 -
ORDER BY+LIMIT在多表 JOIN 下容易触发 filesort，进一步压制索引使用意愿
实操建议：
- 把右表的过滤条件尽量挪到
ON子句里（仅适用于 LEFT JOIN 语义允许的情况） - 检查
WHERE中右表字段是否已包含在复合索引中；否则补覆盖索引，如原索引(code)，WHERE 用到name，就建(code, name) - 用
FORCE INDEX临时验证：在右表名后加FORCE INDEX (idx_name)，看性能是否提升（上线前务必移除）
