最左前缀原则是innodb b+树物理结构决定的访问路径约束，非执行器主动规则：索引(a,b,c)按字典序排序，查询必须从a开始连续匹配，跳过a或范围查询后b/c失效，key_len可验证实际使用列数。
MySQL执行器不直接“应用”最左前缀法则——它是InnoDB存储引擎在B+树遍历过程中自然体现的物理限制，不是执行器主动决策的规则。
联合索引底层是B+树，排序逻辑决定匹配起点
联合索引 (a, b, c) 在InnoDB中就是一棵按字典序排序的B+树：先整体按 a 升序排；a 相同的节点再按 b 排；a 和 b 都相同的再按 c 排。执行器拿到查询条件后，会把请求下推给存储引擎，而InnoDB只能从树根开始、沿着最左列的有序路径往下找。
- 没有
a条件（比如只查WHERE b = 5），InnoDB无法定位到某一段b值的连续区域——因为b在整棵树里是乱序的 - 有
a = 1，就能快速跳到所有a=1的子树分支；再加b = 2，就在该分支内继续二分查找b=2的子段 - 一旦出现
a > 1这类范围查询，InnoDB仍能高效定位起始位置，但后续b和c就不能再用于“跳转”，只能靠顺序扫描或ICP过滤
EXPLAIN输出里 key_len 是关键线索
key_len 字段告诉你实际用到了联合索引的前几列，比看 possible_keys 或 key 更可靠：
MySQL（Linux）
下载
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
-
key_len = 4（假设a是 INT NOT NULL）→ 只用了a列 -
key_len = 8→ 用了a+b（比如b是 INT） -
key_len = 12→ 三列全用上 - 如果
key_len明显小于理论最大值，说明右侧列没参与索引定位，可能被跳过或卡在范围查询之后
WHERE条件顺序不影响索引匹配，但影响可读性与优化器判断
写成 WHERE b = 2 AND a = 1 和 WHERE a = 1 AND b = 2 效果一样——MySQL优化器会重排条件以匹配索引定义顺序。但要注意：
- 别依赖这种重排去“绕过”最左原则，比如
WHERE c = 3 AND a = 1依然只能用a列 - 显式按索引顺序写条件（
a、b、c）更易排查问题，也避免某些旧版本或复杂子查询中优化器误判 - 如果同时存在多个索引，条件顺序可能影响优化器选哪个索引，但不改变单个联合索引内部的匹配逻辑
真正容易被忽略的是：最左前缀不是“语法检查”，而是B+树结构强加的访问路径约束。哪怕SQL写得再漂亮，只要缺失最左列或中间断档，InnoDB就只能退回到更慢的路径——这不是配置问题，也不是执行器bug，是数据物理组织方式决定的硬边界。
