MySQL EXPLAIN 的 filtered 很低时该先查什么

看到 MySQL EXPLAIN 里的 filtered 只有 5% 或 10% 时，先别急着加索引。这个字段表示当前访问方法取到的行，还会有多少比例通过额外条件过滤；它不是“索引有效率”，也不能脱离 rows 单独判断好坏。

排查顺序应是：先用 rows × filtered / 100 算出预计传递行数，再确认估算是否接近实际，最后才决定刷新统计信息或调整索引。

filtered 很低到底说明了什么

在传统表格格式的执行计划里，rows 是访问方法估算要读取的行数，filtered 是条件过滤后的百分比，最大值为 100。比如某表的 rows=2000、filtered=5.00，优化器估计约有 100 行会继续参与后面的连接或结果处理。

这里的“额外条件”通常是当前表的条件、依赖常量或前面表值的条件，并且没有已经被访问方法计算过。若索引先根据 tenant_id 找出一批行，再由 status 过滤，低 filtered 可能只是说明后一个条件很有选择性。相反，如果 rows 本身已经很大，乘积仍然很大，才值得继续追查。

先把完整执行计划算出来

不要只盯着 filtered 一列，先保存完整计划，并按表逐行记录访问路径：

-- 先观察访问方法、索引和额外过滤条件
EXPLAIN
SELECT o.id, o.total_amount
FROM orders AS o
WHERE o.tenant_id = 12
  AND o.status = 'paid'
  AND o.created_at >= '2026-09-01';

重点看四组信息：type 判断访问方式，key 与 key_len 判断实际使用了哪个索引前缀，rows 判断进入当前步骤的估算规模，Extra 则帮助识别是否还有过滤、排序或回表。多表查询还要注意表的顺序，因为前一张表传来的行数会影响后一张表的估算。

如果版本和权限允许，再用实际执行计划对照估算值。估算接近实际而查询仍慢，问题多半是扫描规模、回表或排序成本；估算差距很大，则优先怀疑统计信息、数据倾斜或条件选择性判断。

估算偏差先刷新统计信息

如果表经历过大批量导入、删除或状态比例明显变化，优化器可能仍依据旧的键分布估算。可以先在低峰期更新表统计：

-- 更新表和索引的分布统计，完成后重新执行 EXPLAIN
ANALYZE TABLE orders;

MySQL 文档说明，ANALYZE TABLE 会生成表统计；对 InnoDB 来说，索引基数来自采样估算，因此重复执行得到的数字可能略有差异。更新后重新看执行计划，而不是把一次结果当作永久保证。

当过滤条件落在未建索引、但值分布明显倾斜的列上，可以评估直方图：

-- 仅对分布倾斜的列建立直方图，桶数按数据量和稳定性选择
ANALYZE TABLE orders
  UPDATE HISTOGRAM ON status WITH 32 BUCKETS;

直方图主要帮助优化器估计常量比较的选择性；它不是索引替代品，且数据持续变化后也会变旧。更新后仍需重新 EXPLAIN，确认 rows、连接顺序和代价是否改善。

只有证据支持时才调整索引

若实际扫描量确实过大，再回到查询的联合访问路径：等值条件、范围条件和排序/连接条件是否共同出现，复合索引的列序是否让常用前缀尽早缩小候选集，列上是否套了函数导致索引难以直接使用。不要为了让 filtered 变高而重复建立单列索引。

改索引前后至少保留同一条 SQL 的计划与实际延迟，对比扫描行数、回表、排序、写入代价和其他查询是否受影响。若只是估算不准，刷新统计信息往往比强制索引更容易回滚；若访问路径确实不合适，才建立最小覆盖范围的复合索引并做灰度观察。

常见问题

filtered 越高是不是越好？

不是。它只描述额外条件过滤比例。还要结合 rows、实际延迟、回表和排序成本判断。

filtered 很低就代表索引失效吗？

不代表。索引可能已经先按一个条件取到候选行，低 filtered 只是后续条件继续筛选。

什么时候优先执行 ANALYZE TABLE？

当数据量或分布发生明显变化，且估算行数与实际执行行数偏差较大时优先考虑；更新后要重新查看计划。