复合索引在关联查询中不生效主因是违反最左前缀原则：必须从索引最左列开始连续使用等值条件，跳过最左列（如仅用status）、中间插入范围查询（如created_at > ...）或字段类型不一致导致隐式转换，均会使索引失效。
复合索引在关联查询中不生效，绝大多数情况不是SQL写错了，而是违反了最左前缀原则——哪怕 ON 或 WHERE 条件里“出现了所有索引列”，只要没从最左列开始连续使用，索引就等于没建。
JOIN 条件里只用了复合索引的右列，索引完全失效
比如表 orders 上有联合索引 idx_user_status_created (user_id, status, created_at)，但你在 JOIN 时只拿 status 匹配：
SELECT o.* FROM orders o JOIN users u ON o.status = u.status;
这个 o.status 单独出现，跳过了最左列 user_id，MySQL 无法定位 B+ 树起始位置，只能全表扫描 orders。即使 EXPLAIN 显示 type=ALL，也别怀疑执行计划，这是预期行为。
- 必须确保 JOIN 条件中第一个被用到的索引列，就是复合索引定义里的最左列
- 如果业务上真要按
status关联，要么补上user_id（如o.user_id = u.id AND o.status = 'paid'），要么单独为status建单列索引 -
ON子句的字段顺序不影响优化器重排，但“是否包含最左列”不可绕过
ON + WHERE 混合条件导致部分列无法走索引查找
复合索引能用多少，取决于“等值条件是否连续出现在最左端”。一旦中间插入范围查询或非等值条件，后续列就只剩过滤作用，不参与索引查找。
仍以 idx_user_status_created (user_id, status, created_at) 为例：
SELECT * FROM orders
WHERE user_id = 123
AND status IN ('paid', 'shipped')
AND created_at > '2025-01-01';
这里 user_id 和 status 是等值匹配，可走索引；但 created_at > ... 是范围查询，它后面的字段（如果还有）将无法用于索引定位。当前索引最多用到前两列。
- 范围查询（
>、、<code>BETWEEN、LIKE 'abc%'）是“断点”，其右侧字段不参与索引查找 - 如果查询常带时间范围，又需要高效过滤
status，应把status放在created_at左侧，但前提是status的区分度和查询频率允许 -
IN算等值条件，不会截断，但若IN值过多，优化器可能放弃索引转为全表扫描
关联字段类型不一致，隐式转换让索引直接失效
即使 ON 条件满足最左前缀，若关联字段类型不一致（比如一边是 VARCHAR，一边是 INT），MySQL 会自动做类型转换，导致索引无法使用。
典型场景：用户表 users.id 是 BIGINT，订单表 orders.user_id 是 VARCHAR，却这样写：
SELECT * FROM orders o JOIN users u ON o.user_id = u.id;
MySQL 实际执行的是 CONVERT(o.user_id, SIGNED) = u.id，而函数操作作用于索引列，索引失效。
- 用
EXPLAIN查看Extra列，若出现Using where; Using join buffer或空值，大概率存在隐式转换 - 用
SHOW CREATE TABLE对比两边字段类型，确保完全一致（包括字符集、是否允许 NULL） - 宁可在应用层做显式转换，也不要依赖数据库隐式转换
最左前缀不是“语法检查规则”，而是 B+ 树物理结构决定的硬约束。你看到的“没走索引”，往往不是优化器偷懒，而是它根本没法从树根往下二分——因为起点都找不到。
