MySQL EXPLAIN 中 filtered 很低怎么办：选择性、统计信息与执行计划复核

排查一条慢查询时，EXPLAIN 里最容易被误读的字段之一就是 filtered。它显示为 8.00，并不直接说明“索引只用了 8%”，也不能单独证明应该再建一个索引。这个数字更接近优化器对当前表访问后、剩余条件还能筛掉多少行的估算，必须和 type、key、rows 以及实际执行情况一起看。

先看清 filtered 在执行计划里表示什么

假设有一张订单表：

CREATE TABLE orders (
  id BIGINT PRIMARY KEY,
  tenant_id BIGINT NOT NULL,
  status VARCHAR(20) NOT NULL,
  created_at DATETIME NOT NULL,
  amount DECIMAL(10, 2) NOT NULL,
  KEY idx_tenant_created (tenant_id, created_at)
);

查询某个租户最近一周的已支付订单：

EXPLAIN SELECT id, amount
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-08-18 00:00:00'
  AND status = 'paid';

如果计划中 rows=125000、filtered=8.00，可以先把它理解为：优化器预计访问约 125000 行，其中约 8% 能通过剩余条件。这个乘积只是估算线索，不能拿来当作真实返回行数。

用 rows、filtered 和 type 一起判断问题位置

排查时我会先记录这几列，而不是看到 filtered 低就立即建索引：

真正危险的组合通常是 rows 很大、filtered 很低，并且查询还要回表读取大量列。相反，rows 只有几百，即使 filtered 是 5，也未必值得增加索引维护成本。

在 EXPLAIN ANALYZE 中复核估算是否失真

MySQL 8.0 可以用 EXPLAIN ANALYZE 观察实际执行行数与耗时。为了避免缓存和参数差异影响判断，测试时固定租户、时间范围和状态值，并在低峰期对副本执行：

EXPLAIN ANALYZE
SELECT id, amount
FROM orders
WHERE tenant_id = 42
  AND created_at >= '2026-08-18 00:00:00'
  AND status = 'paid';

重点对照每个 iterator 的 rows 估算和实际行数。如果估算 125000、实际只有 900，优化器可能高估了；如果估算 125000、实际有 900000，则低估更值得警惕。后者会影响 join 顺序、临时表选择和内存预算，问题不一定能靠一个新索引解决。

统计信息过期时先做什么

批量导入、归档或某个状态突然集中后，索引仍然存在，但优化器手里的数据分布已经过时。先在可控窗口执行：

ANALYZE TABLE orders;
SHOW INDEX FROM orders;

重新生成计划后，如果 rows 和 filtered 明显接近实际，再继续观察。对于倾斜严重的列，还要检查直方图是否适合当前版本与工作负载。统计信息更新会改变计划，生产环境应先在副本和代表性参数集上比较，而不是直接把它当成无风险修复。

什么时候值得调整联合索引

只有当访问路径本身没有把高选择性条件提前利用，或者回表成本确实成为瓶颈时，才考虑索引设计。对上面的查询，可以比较 (tenant_id, created_at) 与包含 status 的方案，但不能只按“选择性最高的列放最前”套公式。

• 等值条件：tenant_id = 42 能稳定缩小租户范围，通常是重要的前导列。
• 范围条件：created_at >= ... 会影响后续列继续参与有序定位的能力。
• 回表成本：如果只返回 id, amount，覆盖索引可能减少随机读取，但会增加写入和空间成本。

改索引前先保存旧计划、典型参数和执行耗时；改完后至少覆盖空结果、少量结果、热门租户和时间范围较大的情况。一个只在单一参数上变快的索引，可能把其他租户的计划推向更差的方向。

常见问题

filtered 越高就一定越好吗？

不是。它是优化器的保留比例估算。最终是否高效，还要看访问行数、回表、排序、连接和实际耗时。

filtered 很低需要马上加 status 索引吗？

不需要。先用 EXPLAIN ANALYZE 验证实际扫描规模，再检查数据分布和统计信息；单列索引可能还不如合适的联合或覆盖索引。

ANALYZE TABLE 会改变业务数据吗？

它主要更新表和索引的统计信息，但可能让后续查询选择不同计划。应在副本或低峰窗口先验证，并准备好计划回归记录。

最后留一份可复查的计划记录

把 SQL、参数、MySQL 版本、EXPLAIN 与 EXPLAIN ANALYZE 输出、统计信息更新时间和索引变更写进同一条工单。下次数据量或状态分布变化时，先复用这组基线，再判断是估算偏差、访问路径问题，还是业务数据真的变了。这样处理 filtered，结论会比“数字低所以加索引”可靠得多。