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+ 树就无法直接比对原始值：

• 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 本身不破坏索引逻辑，但优化器为右表选驱动路径时，仍严格依赖最左前缀：

win可用的mysql指令skill

安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。

下载

• 右表有索引 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 不足以触发索引定位——那只是排序或分组阶段的利用，不是查找起点。