MySQL优化器不走复合索引最左前缀，主因是WHERE或ON中缺失最左列；函数/隐式转换、JOIN字段类型不一致、仅ORDER BY含最左列等也会导致索引失效。
MySQL 查询优化器“不走”复合索引的最左前缀，通常不是它拒绝走，而是你写的条件根本没提供最左列——它想走也找不到入口。B+ 树索引不是开关，是路径；没有最左列，就像导航时没输出发城市，系统连该打开哪本电话簿都不知道。
WHERE 条件里缺了最左列，索引直接不可用
复合索引 idx_user_status_ctime(user_id, status, create_time) 的 B+ 树按 user_id 全局排序，status 只在每个 user_id 分支内有序，create_time 更是只在 user_id + status 完全相同时才局部有序。所以：
-
WHERE status = 'paid'→ 优化器无法定位任何user_id分支，只能全表扫描（type=ALL） -
WHERE user_id = 100→ 能快速跳到对应分支，走索引（type=ref或range） -
WHERE user_id = 100 AND status = 'paid'→ 在该分支内继续下钻，仍走索引 -
WHERE status = 'paid' AND user_id = 100→ 和上一条等价，优化器会自动调整顺序，不影响命中
最左列被函数或隐式转换包裹，索引彻底失效
哪怕 WHERE 里写了最左列，只要它被运算或类型转换干扰，B+ 树就无法直接比对原始值：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
-
WHERE YEAR(create_time) = 2025→create_time是最右列，但即使它是第一列，函数也会让整条索引失效 -
WHERE user_id + 0 = 10086→ 数值列加 0 是隐式计算，user_id不再是裸列 -
WHERE user_id = '10086'（user_id是INT）→ 字符串转数字发生在参数侧，不影响索引使用 -
WHERE CAST(user_id AS CHAR) = '10086'→ 函数作用于列，索引失效
LEFT JOIN 中右表连接字段未覆盖最左前缀
JOIN 本身不破坏索引逻辑，但优化器为右表选驱动路径时，仍严格依赖最左前缀：
- 右表有索引
idx_motorcade_user_del(motorcadeId, userId, isDelete) -
ON u.motorcadeId = a.motorcadeId→ 满足最左列，可走索引 - 若再加
WHERE u.isDelete = 0却没带上userId→isDelete不是最左列，优化器可能放弃该索引，改用全表扫或临时表 - 更隐蔽的是字段类型不一致：比如左表
motorcadeId是BIGINT，右表是VARCHAR→ 隐式转换发生于右表列，索引失效
EXPLAIN 看不到 key，但 rows 很小？可能是优化器主动弃用
有时 EXPLAIN 显示 key=NULL，但 rows 很小，说明优化器评估后认为全表扫比走索引更便宜——常见于：
- 表数据量极小（如
- 最左列选择性极差（如
is_delete TINYINT只有 0/1，重复度高），索引区分度低 - 查询返回大量字段，而索引非覆盖，回表代价 > 全表扫描代价
- 统计信息过期（
ANALYZE TABLE未执行），优化器误判行数
真正容易被忽略的点是：最左列必须出现在 WHERE（或 ON）中，仅出现在 ORDER BY 或 GROUP BY 不足以触发索引定位——那只是排序或分组阶段的利用，不是查找起点。
