MySQL 联合索引跳过第一列时为什么可能不生效

给表建立了 (tenant_id, status, created_at) 联合索引，查询却只写 status，这时看到“索引没生效”并不奇怪。联合索引按列顺序组织成一棵复合有序结构，能直接定位的通常是连续的最左前缀；但“没有最左前缀”不等于优化器在所有版本和数据分布下都绝对不会读索引，最终仍要以 EXPLAIN 的实际计划为准。

判断口诀是：先看 WHERE 是否从联合索引第一列开始，再看是否在中间遇到范围或函数，最后用 EXPLAIN 的 key、key_len 和 rows 确认优化器的真实选择。

先看联合索引的列顺序和连续前缀

假设订单表有如下索引：

-- 这个索引先按租户分组，再按状态和创建时间排序
CREATE INDEX idx_order_tenant_status_created
ON orders (tenant_id, status, created_at);

-- 这类查询从第一列开始，可以沿联合键直接缩小范围
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 42 AND status = 'paid';

它的有效前缀可以理解为 (tenant_id)、(tenant_id,status) 和 (tenant_id,status,created_at)。查询条件在 SQL 中换个书写顺序通常不影响这一点，因为优化器会分析谓词；真正重要的是条件是否覆盖索引左侧连续列。

跳过第一列时为什么可能失去定点查找能力

把联合索引想成先按 tenant_id 排序，再在每个租户组内按 status 排序。只知道 status='paid' 时，MySQL 不知道应该进入哪个租户组；即使索引叶子节点里确实存着 status，也缺少一个连续的起点范围。因此“索引里有这个字段”和“能用它快速定位”是两件事。

中间条件出现范围也会改变后续列的作用。例如：

-- 范围先截断了可精确定位的连续边界，created_at 不再等同于独立首列
SELECT id
FROM orders
WHERE tenant_id = 42
  AND status >= 'paid'
  AND created_at >= '2026-01-01';

这里第一列仍然有价值，第二列也能形成范围；但不能简单宣称第三列一定继续用于精确查找。对列做函数、隐式类型转换，或者把条件写成复杂的 OR，也可能让可用的索引边界变窄。另一方面，某些版本和场景存在跳跃扫描、索引合并或覆盖读取等特殊路径，所以标题中的“可能”很重要：不要只凭最左匹配口诀下结论。

用 EXPLAIN 判断是没命中还是不值得用

先看候选集合，再看实际选择：

-- 只观察优化器计划，不执行这条查询
EXPLAIN SELECT id, status, created_at
FROM orders
WHERE status = 'paid';

possible_keys 表示优化器认为可能考虑的索引，key 才是本次计划选中的索引；key_len 可帮助判断用了联合键的多长前缀，rows 是估算需要检查的行数。若 key 为 NULL，说明这次没有选择索引查找；若选中了目标索引，也要结合 type、过滤条件和返回列判断是否真的减少了工作。

估算明显不符合数据现状时，可以在结构变更前更新统计信息：

-- 表数据分布变化后更新优化器使用的统计信息
ANALYZE TABLE orders;

这不是强制使用某个索引的开关，只是让成本估算更接近当前分布。没有必要先上 FORCE INDEX：提示会把优化器限制在特定选择上，数据量和分布变化后反而可能留下新的慢查询。

按查询形态调整索引而不是强行加提示

如果业务长期存在“只按 status 查”的请求，且它确实需要低延迟，就应把真实查询集合纳入索引设计，例如补充 (status, created_at)，而不是期待 (tenant_id,status,created_at) 永远兼顾两种入口。索引越多，写入、更新和存储成本越高，所以先用慢查询样本和 EXPLAIN 确认频率，再决定是否新增。

上线前可按下面的顺序检查：

1. 记录完整 SQL、参数类型、排序和分页条件，确认没有把一个查询误当成所有查询。
2. 核对联合索引定义与 WHERE、JOIN、ORDER BY 的实际列顺序。
3. 检查第一列是否缺失，中间是否出现范围、函数、隐式转换或 OR。
4. 对代表性数据执行 EXPLAIN，记录 key、key_len、rows 和访问类型。
5. 在测试环境比较改写 SQL、重排索引、补充单列索引和更新统计信息的代价，再灰度观察。

相关问题

WHERE 条件顺序必须和索引顺序完全一致吗？

不必。优化器会分析等值条件；关键是谓词能否覆盖联合索引的连续左侧列，而不是 SQL 文本中哪一项先出现。

跳过第一列是不是一定会全表扫描？

不是绝对结论。通常失去该联合键的直接定点查找能力，但优化器仍可能选择其他索引策略；以当前版本和实际 EXPLAIN 为准。

看到 possible_keys 有目标索引就算生效了吗？

不算。必须看 key 是否选中它，并用 key_len 和 rows 判断使用深度与估算范围。

可以直接加 FORCE INDEX 解决吗？

一般不应作为第一步。先修正索引顺序、查询形态或统计信息；只有明确知道成本模型选择错误且有回归依据时，才评估提示的长期维护成本。