联合索引(a,b,c) ，查询条件 where b > xxx and a = x 会生效吗
where b > ... and a = ... 通常可使用 (a,b,c) 的 a、b 前缀，但范围后的列能否继续缩小扫描需结合计划判断。
直接结论
对联合索引 (a,b,c)，条件 a = x AND b > y 通常可以使用索引：先按 a 的等值范围定位，再在该范围内按 b 做范围扫描。SQL 中条件书写顺序不决定索引使用，所以题目写成 b > y AND a = x 结论相同。常见说法“遇到范围后后面的列失效”需要精确化：c 往往不能继续缩小索引扫描区间，但可能用于索引条件下推、过滤、覆盖或排序，必须查看具体版本和执行计划。
原理与步骤
多列索引按索引定义中的列从左到右排序，可高效利用任意最左前缀。a 等值固定后，b 的有序性可建立一个连续或若干范围；b 一旦是开放范围，c 在不同 b 值下重新排序，通常无法形成单一连续的 c 搜索边界。若缺少 a 而只有 b 条件，一般不能按普通最左前缀直接定位，但优化器可能因跳跃扫描等能力或成本选择出现不同计划，因此应避免把经验口诀当作永恒规则。
工程场景
订单索引 (tenant_id, created_at, status) 下，tenant_id 等值加 created_at 范围适合读取某租户时间段。若还经常按 status 强过滤，应根据真实查询评估 (tenant_id,status,created_at) 或额外索引，同时考虑排序和分页。把 select 列包含进索引可减少回表，但过宽索引会增加写放大和缓存压力。参数分布、返回行比例与统计信息会改变优化器成本，测试不能只用几行样例数据。
验证与边界
判断“生效”至少要区分用于定位、用于过滤、用于覆盖和最终是否真的选择该索引。EXPLAIN 的 key、key_len、rows、filtered 以及 EXPLAIN ANALYZE 的实际行数共同提供证据；只看到 key 名称不等于所有列都参与搜索。函数、隐式类型转换、不同排序方向和字符集也可能影响利用方式。结论应限定 MySQL 版本、索引定义、数据分布和查询投影，并以实际计划为最终依据。
答题练习
- 1条件书写顺序不影响逻辑
- 2a 等值后 b 范围可定位
- 3范围后的 c 仍可能过滤或覆盖
常见错误
- 把范围后失效解释为完全无用
- 只看 EXPLAIN 的 key 不看扫描范围
可能追问
- 如何用 key_len 判断使用前缀
- 列顺序如何兼顾过滤与排序
来源记录
- 原始来源
- 小林coding
- 来源页面
- MySQL面试题
- 最近收录
- 2026-07-04
- 官方复核
- MySQL 官方文档