联合索引底层是单棵B+树，按(a,b,c)三元组整体排序，非多棵树叠加；根与中间节点仅存a的分割值，故WHERE b=2等跳过最左列的查询无法使用该索引。
联合索引底层是单棵B+树，不是多棵树
很多人误以为 INDEX (a, b, c) 是“a一棵树、b一棵树、c一棵树”的叠加，其实它只建了一棵B+树，所有叶子节点按 (a, b, c) 三元组整体排序。就像字典里词条是“张三丰”“张无忌”“李四光”这样排的，不是先排姓、再单独排名、再单独排字号。
所以当你执行 WHERE b = 2，MySQL根本没法从这棵树的根节点开始二分——因为根节点和中间节点存的都是 a 的分割值（比如 a b 的任何边界信息。叶子节点里 b 值本身也无序（仅在相同 a 下有序），无法做全局二分查找。
跳过最左列时，连扫描起点都找不到
B+树查找必须从根往下定位一个“起始页”，这个动作依赖最左列的等值条件来缩小搜索路径。没有 a = ?，就等于不知道该往左子树还是右子树走，只能放弃索引，退化为全表扫描。
-
WHERE a = 1 AND b = 2：用a = 1快速落到某段叶子页，再在这些页内利用b有序性继续过滤 -
WHERE b = 2：没有a约束，整棵树对b来说就是乱序的，MySQL连“从哪一页开始扫”都不知道 -
WHERE a IN (1,2) AND b = 2：IN是等值组，仍可定位多个起始页，后续b仍有效
EXPLAIN 中 key_len 不为 0 就代表用了索引？
不一定。比如 INDEX (a, b, c)，执行 WHERE a = 1 AND c = 3，EXPLAIN 显示 key_len = 4（假设 a 是 INT），说明只用了第一列；但 c 实际没走索引，只是被当作普通过滤条件在引擎层逐行判断。别被 key_len 迷惑，要看 Extra 字段是否出现 Using index condition 或 Using where，并结合实际查询性能验证。
MySQL 数据库管理技能，能够通过自然语言查询和管理数据库，支持 SELECT/INSERT/UPDATE/DELETE、表管理、备份恢复等操作。当用户提及 MySQL、数据库查询、建表或数据备份时使用此技能。
范围查询后右侧字段失效，本质也是丢失有序性
WHERE a = 1 AND b > 10 AND c = 3 中，b > 10 定位出的是一批叶子节点（如 (1,11,foo)、(1,12,bar)、(1,15,baz)），这些节点中 c 值是 foo, bar, baz —— 它们不再满足 B+ 树定义的全局有序，自然不能对 c 做二分。这个“断连”不是 MySQL 故意限制，而是 B+ 树结构决定的物理事实。
真正容易被忽略的是：即使你写了 ORDER BY b, c，只要 WHERE 没覆盖到 b 和 c 的连续前缀，排序也无法复用索引顺序。索引能不能用于排序，和能不能用于过滤，取决于同一套最左前缀逻辑。
