最左匹配是b+树物理结构决定的必然限制，而非规则失效；联合索引按定义列顺序严格排序，缺失最左列则无法定位起始页，导致全表扫描。
最左匹配不是“规则失效”，而是B+树物理结构天然不支持跳级定位——它根本没法跳。
联合索引的B+树只按定义顺序排序
联合索引 idx_user_product_time(user_id, product_code, order_time) 的B+树，数据是严格按这三列拼起来的字典序排列的：
先整体按 user_id 分块，每块内再按 product_code 排，再按 order_time 排。
没有 user_id 这个起点，数据库连“从哪一页开始查”都不知道。
常见错误现象：
• EXPLAIN SELECT * FROM order_records WHERE product_code = 'P10086' 显示 type: ALL
• EXPLAIN SELECT * FROM order_records WHERE order_time > '2023-01-01' 也走全表扫描
- 不是MySQL故意“不走索引”，而是B+树没存
product_code单独的有序序列 - 哪怕
product_code选择性极高，优化器也没法凭空造出它的索引路径 - 即使加了
FORCE INDEX，也会报错或被忽略（InnoDB不支持强制跳过最左列）
为什么加了WHERE user_id = ? 就能救活后续字段？
一旦有了最左列的等值条件，B+树就锁定了一个连续的数据子区间。在这个区间内，product_code 和 order_time 才真正具备局部有序性，才能被高效利用。
典型有效组合：
• WHERE user_id = 'U123' → 用到 user_id
• WHERE user_id = 'U123' AND product_code = 'P10086' → 用到前两列
• WHERE user_id = 'U123' AND product_code > 'P10000' → product_code 可范围扫描，但 order_time 不再参与排序（中断点）
- 范围查询（
>、、<code>BETWEEN）会让后续列失去索引排序能力，只能用于过滤，不能加速范围或排序 -
IN是例外：它本质是多个等值，所以user_id = ? AND product_code IN ('A','B')后面的order_time仍可生效
隐式“跳过”最左列的坑：类型不匹配或函数包裹
你以为写了 user_id，但实际没生效，可能是因为：
- 字段是
VARCHAR，却传了数字：WHERE user_id = 123→ 触发隐式转换，索引失效 - 加了函数：
WHERE UPPER(user_id) = 'U123'→ 索引列被计算，无法直接比对 - 用了表达式：
WHERE user_id + '' = 'U123'→ 同样破坏原始值存储形式
这类写法会让优化器“看不见”最左列，等价于没写，整个联合索引退化为无效状态。
真正能绕过最左限制的只有两种情况
不是所有“跳过”都绝对不行，但必须满足极苛刻前提：
-
覆盖索引 + IS NULL 条件：如
WHERE user_id IS NULL AND product_code = 'P10086'，且索引包含所有SELECT字段，部分版本可能利用NULL分支做特殊优化（非常规，不可依赖） -
MySQL 8.0+ 函数索引：单独为
product_code建函数索引INDEX idx_product (product_code)，但这已不属于原联合索引的“最左匹配”范畴
别指望优化器自动补全缺失的最左列——它不会猜，也不会拆解联合索引去重建单列顺序。设计索引时漏掉高频查询的前置列，后期基本只能重建索引或改SQL逻辑。
