复合索引（也叫联合索引）的底层存储结构是B+树，索引的排序规则按照从左到右的字段顺序进行。当SQL查询条件无法匹配索引最左边的列时，索引就无法被有效使用。这种机制就是常说的最左前缀匹配原则，简称左匹配原则。在关联查询中，由于涉及多个表的连接条件和过滤条件，很容易违反这个原则，导致明明建了复合索引却无法命中。
复合索引与左匹配原则的关系
假设有一张订单表 orders，包含字段 user_id、status、created_at，并在这三个字段上创建了一个复合索引 idx_user_status_time（顺序为 user_id、status、created_at）。该索引的B+树会先按user_id排序，相同user_id内再按status排序，最后按created_at排序。只有当查询条件包含最左边的字段user_id时，这个索引才能被充分利用。如果跳过了user_id，直接使用status或created_at作为条件，索引无法定位到起始范围，因此不会走索引或者只能部分走索引。
在关联查询中，情况会更复杂。假设有用户表 users 和订单表 orders，我们要查询某个状态下的用户订单：
-- 错误的写法：关联条件中orders.user_id没有出现在复合索引最左侧 SELECT u.name, o.order_no, o.amount FROM users u JOIN orders o ON o.user_id = u.id WHERE o.status = 'paid' AND o.created_at > '2023-01-01';
上面的查询中，WHERE条件直接使用了索引的第二列status和第三列created_at，跳过了最左列user_id，因此复合索引idx_user_status_time的user_id列没有被任何条件约束，索引无法从最左侧定位，只能进行全索引扫描甚至全表扫描。正确做法应该是把user_id放到条件中：
-- 正确的写法：匹配了左前缀，并且过滤条件顺序与索引一致 SELECT u.name, o.order_no, o.amount FROM users u JOIN orders o ON o.user_id = u.id WHERE o.user_id = 123 AND o.status = 'paid' AND o.created_at > '2023-01-01';
关联查询中常见的左匹配违规场景
1. 连接条件中跳过最左列
关联查询中，连接条件本身也会参与索引匹配。如果连接条件的列不是复合索引的最左列，就很容易失效。比如在订单明细表order_items上建了复合索引idx_order_item(order_id, product_id, quantity)：
-- 连接条件用了product_id，跳过了order_id SELECT oi.* FROM orders o JOIN order_items oi ON oi.product_id = o.product_id WHERE oi.quantity > 10;
上述查询中，oi.product_id是索引的第二列，被跳过了，所以索引无法用于连接。应该把order_id也加入连接条件，或者调整索引顺序。
2. WHERE条件中使用了范围查询或函数
左匹配原则还要求，当复合索引某一列上使用了范围查询（>、<、BETWEEN、LIKE前缀模糊等），后续列将无法使用索引。例如：
-- 范围查询在第二列，导致第三列无法走索引 SELECT * FROM orders WHERE user_id = 100 AND status > 'pending' AND created_at > '2023-01-01';
这里尽管用了user_id，但status使用范围条件，created_at就无法再走索引了（只能对user_id和status进行索引扫描，created_at需要回表过滤）。如果想完全命中索引，可以将范围条件放到最后：
-- 调整条件顺序：等值条件在前，范围条件在后 SELECT * FROM orders WHERE user_id = 100 AND status = 'paid' AND created_at > '2023-01-01';
3. 关联表时对索引列进行了隐式类型转换
当字段类型为字符串时，如果关联条件中传入的值为数值类型，MySQL会进行隐式转换，导致索引失效。例如：
-- user_id是varchar类型，但连接条件中使用了数值 SELECT * FROM users u JOIN orders o ON o.user_id = u.id WHERE u.user_id = 123;
隐式类型转换会破坏索引的比较规则，使得左匹配原则无法生效。解决方案是保持类型一致：u.user_id = '123'。
如何确认当前查询是否命中复合索引
使用 EXPLAIN 命令查看执行计划，关注 key（实际用到的索引）和 key_len（索引使用的字节长度）。如果 key_len 小于复合索引各列可能的长度之和，说明索引只被部分使用。例如复合索引包含三个字段（int(4) + varchar(20) + datetime(5)），正常命中的 key_len 应较大，若 key_len 仅为4，则说明只使用了第一列。
EXPLAIN SELECT * FROM orders WHERE user_id = 100 AND status = 'paid'G
如果 Extra 中显示 Using index condition 或 Using where，也提示索引使用不完整。
调优建议
- 调整索引顺序：将最常作为等值条件的列放在左边，范围条件列放在右边，关联条件列尽量靠左。
- 拆分复合索引：如果查询模式多样，可以考虑建立多个单列索引（但MySQL的索引合并能力有限，多列索引通常更优）。
- 改写SQL：确保WHERE条件和JOIN条件的列顺序与索引左前缀一致，且避免在索引列上使用函数或隐式转换。
- 使用覆盖索引：如果查询的所有列都包含在复合索引中，可以避免回表，即使部分索引被跳过也能提升性能。
总结
SQL关联查询无法命中复合索引，90%的情况都是因为违反了左匹配原则。理解索引的B+树排序规则后，自然能明白为什么查询条件必须从最左列开始，并且不能跳过中间列。编写SQL时，应当先检查WHERE条件和JOIN条件是否都包含了索引的最左列，并且尽量让等值条件在前、范围条件在后。通过EXPLAIN分析执行计划，可以快速定位索引使用情况。只要掌握了左匹配原则，就能避免大部分索引失效问题，写出高效的关联查询。