最左前缀原则源于b+树物理结构而非mysql规则；联合索引(a,b,c)中，缺失a则b、c无序，无法二分查找；where顺序不影响优化器判断，但列缺失或范围查询会截断索引；order by也受此约束，错位即filesort；唯一验证方式是explain。
最左前缀不是MySQL的“规则”，而是B+树的物理事实
联合索引 (a, b, c) 在 InnoDB 中就是一棵按字典序构建的 B+ 树：先按 a 全局排序；a 相同的节点，再按 b 排序；a 和 b 都相同的，才按 c 排序。这不是优化器“决定”怎么用，而是数据在磁盘上就长这样。
跳过 a 直接查 b = 5，就像翻纸质电话簿不看姓氏、只找“小明”——数据库没法定位起始页，只能全表扫描。
所以所谓“必须遵循”，本质是：没有 a，b 和 c 在索引中根本就不是有序的，无法二分查找。
WHERE 条件顺序不影响，但列是否存在和是否范围查询直接影响索引截断点
MySQL 优化器会自动重排 WHERE 条件顺序，所以 WHERE b = 2 AND a = 1 和 WHERE a = 1 AND b = 2 效果一样，只要 a 存在且等值，就能用上 (a, b) 段。
但以下情况会硬性中断索引使用：
-
WHERE a = 1 AND c = 3→ 只能用a，c不参与定位（key_len仅含a字节数），c = 3是 Server 层回表后逐行过滤 -
WHERE a > 1 AND b = 2 AND c = 3→a > 1是范围，b和c在对应子树内无序，b、c全部失效 -
WHERE b = 2 AND c = 3→key为NULL，直接退化为全表扫描
ORDER BY 同样受最左前缀约束，错位即 filesort
索引 (a, b, c) 的有序性只保证：ORDER BY a、ORDER BY a, b、ORDER BY a, b, c 可免排序；其余都触发 Using filesort。
常见误判：
-
SELECT * FROM t WHERE a = 1 ORDER BY b, c→ ✅ 有效（a = 1子集内b, c有序） -
SELECT * FROM t WHERE a > 1 ORDER BY b, c→ ❌ 必filesort（a > 1对应多个不连续子树，b, c整体无序） -
SELECT * FROM t ORDER BY b, a→ ❌ 完全不匹配索引顺序
真正容易被忽略的点：explain 是唯一验证手段
别靠“我写了 WHERE a = 1 AND b = 2”就认为索引用上了。必须看 EXPLAIN 输出：
-
key字段非NULL才说明实际用了索引 -
key_len值要对照字段类型算——比如INT是 4 字节，VARCHAR(10)是 10 × 字符集字节数 + 长度字节，它反映实际匹配了几列 -
Extra出现Using where; Using index表示覆盖索引；出现Using where但没Using index，大概率是回表后过滤
最左前缀是否生效，不取决于 SQL 写法或经验猜测，只取决于 EXPLAIN 里 key_len 和 Extra 的组合结果。
