MySQL 联合索引中间列不参与过滤还能用到后缀列吗

不能把“索引里有后缀列”理解成“后缀列一定能参与定位”。假设索引是 (tenant_id, status, created_at)，查询只写了 tenant_id 和 created_at，MySQL 通常可以先按 tenant_id 缩小范围，但缺失的 status 会打断连续的最左前缀；created_at 往往只能继续做索引条件检查或回表后的过滤，不能等价替代 (tenant_id, created_at) 索引。最终是否真的走这条路径，仍要看执行计划。

判断口诀：中间列缺失时，后缀列可能“被读到”，但不一定能“用来定位”。先看 key_len 和访问类型，再看是否出现 Using index condition；不要只看 possible_keys。

先把“使用索引”和“用后缀列定位”分开

用一个订单表说明最容易混淆的场景：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  tenant_id INT NOT NULL,
  status VARCHAR(20) NOT NULL,
  created_at DATETIME NOT NULL,
  KEY idx_tenant_status_created (tenant_id, status, created_at)
);

-- 省略 status，测试中间列缺失对 created_at 的影响
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-09-01';

这棵 B+Tree 先按 tenant_id 排序，再在相同租户内按 status 排序，最后才按 created_at 排序。没有 status 时，某个租户下的日期值被多个 status 分段隔开，优化器不能把它们当成一个连续的 (tenant_id, created_at) 范围。

所以“能用”至少有三种含义：用 tenant_id 做范围查找；在索引记录上检查 created_at；或者干脆扫描更大的索引/数据范围后再过滤。它们的回表次数和成本不同，不能用一句“走了索引”概括。

为什么 created_at 不能跨过 status 直接变成范围条件

联合索引可以看成把多个字段拼成有序键。对 (a,b,c) 来说，a=? AND b=? AND c>? 能形成连续的范围；而 a=? AND c>? 只固定了第一段，第二段 b 仍有很多取值。数据库如果要用 c 继续定位，就必须在每个 b 分段中寻找日期范围，这不再是普通的单段范围查找。

这并不代表 created_at 永远没有价值。InnoDB 二级索引上，Index Condition Pushdown 可能在读取索引项时先判断索引中已有的列，减少不满足条件的回表；但它优化的是“少回表”，不是把中间缺口变成连续索引前缀。若查询只取索引里已有的列，还可能出现覆盖索引，成本又会不同。

另外，字符串列、字符集、可空性和主键长度都会影响 key_len，因此不要把某个示例的字节数硬套到所有表上。关键是观察它是否只用到 tenant_id，以及 created_at 出现在访问条件还是过滤条件中。

用执行计划确认：后缀列到底参与了哪一层

先用普通计划定位方向，再用实际执行计划观察真实行数。生产数据量较大时，建议在同样的参数和时间范围下分别记录执行时间、扫描行数、回表行数或计划中的实际行数，形成可复现的基线。

-- 查看候选索引、访问类型、key_len 和过滤信息
EXPLAIN
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-09-01';

-- 在可控环境观察实际执行行数和耗时
EXPLAIN ANALYZE
SELECT id, status, created_at
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-09-01';

如果同一个 tenant_id 下的数据很多，缺失 status 造成的扫描范围就可能明显放大；如果租户选择性很高，原索引仍可能已经足够。性能结论必须建立在自己的数据分布上，不能只根据列顺序下定论。

什么时候应该调整索引顺序或补一棵索引

如果最常见的查询就是“租户 + 创建时间”，并且 status 不是稳定的过滤条件，可以考虑 KEY (tenant_id, created_at)。如果查询经常是“租户 + 状态 + 时间”，原来的三列顺序更贴合；若两类查询都很重要，再比较增加索引带来的存储空间和写入维护成本。

不要为了让一条 SQL 看起来完整就强行补上无意义的 status 条件，也不要直接使用 FORCE INDEX 掩盖统计信息或数据分布问题。先用相同数据集对比两种索引的执行计划与实际耗时，再决定是否灰度上线。

MySQL 8.4 还有 Skip Scan：在某些条件下，优化器可以枚举前导列的不同值，对后续范围做多次扫描。它有明确限制，也受成本模型影响；看到版本支持不代表每个“跳列”查询都会采用。若计划显示 Using index for skip scan，应把它当作当前计划的特殊访问方式，继续观察数据增长后的稳定性。

常见问题

中间列缺失时，后缀列是不是完全没用？

不是。它可能参与 Index Condition Pushdown、覆盖索引读取或过滤，但通常不能像连续左前缀那样直接缩小普通查找范围。

看到 possible_keys 包含联合索引，就说明后缀列生效了吗？

不是。possible_keys 只是候选集合，实际要结合 key、key_len、type、Extra 和实际执行行数判断。

MySQL 8.4 的 Skip Scan 能解决所有跳列查询吗？

不能。它有单表、谓词形态、索引覆盖和成本等限制；即使可用，数据分布变化也可能让优化器选择别的路径。

最终决策可以压缩成一句话：先确认最常见的过滤组合，再用执行计划证明列顺序是否匹配；需要稳定的“租户 + 时间”范围时，独立的 (tenant_id, created_at) 往往比期待优化器跨过 status 更可控。