索引包含三个字段，不意味着任意一个字段单独查询都能获得相同收益。
本文使用MySQL 5.6、InnoDB 与独立测试数据库。数据库研究要同时观察表结构、数据分布和实际语句。本文讨论 InnoDB（事务存储引擎），不把其他存储引擎或后续版本特性当作相同行为。
1. 从现象推到机制
联合 B-tree（平衡树索引）按字段顺序组织键值。前导等值条件可以缩小连续范围，范围条件之后的字段未必还能同样缩小扫描区间，但仍可能用于过滤或覆盖。是否选索引还受数据分布与成本估算影响。
图中的四个节点分别表示业务查询、联合顺序、范围定位、执行计划。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
为演示订单建立用户、状态和编号索引，用 EXPLAIN 比较不同条件组合。固定数据规模，避免在只有几行的表上得出通用性能结论。
1
2
3
4
CREATE INDEX ix_order_owner_status_id
ON orders(owner_id, status, id);
EXPLAIN SELECT id FROM orders
WHERE owner_id = 7 AND status = 1 ORDER BY id;
先保存建表语句、索引与隔离级别，再准备固定演示数据。并发行为使用两个独立连接按顺序执行；执行计划、锁等待和最终数据需要结合，单看查询耗时不足以解释原因。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 仅按前导字段查询 | 可能利用有序前缀缩小范围 |
| 跳过前导字段过滤 | 不能假定同等定位能力 |
| 查询字段被索引覆盖 | 可能减少回表访问 |
对照 1：仅按前导字段查询
可能利用有序前缀缩小范围。观察时记录key 与访问类型。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：跳过前导字段过滤
不能假定同等定位能力。观察时记录实际执行计划与扫描估计。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：查询字段被索引覆盖
可能减少回表访问。观察时记录Extra 与所需列范围。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
更多索引会增加写入维护成本和存储。先围绕高价值查询组合设计，再用真实分布验证，避免为每个字段单独建一个索引。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“查询字段被索引覆盖”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
