filtered值越低越好，表示where条件过滤越精准；它反映索引命中后仍需保留的行比例，需结合rows判断实际过滤效果，低filtered但大rows可能暴露索引选择性差或统计信息过期。
filtered 值低 ≠ 索引没用，但意味着过滤效率差
filtered 列显示的是 MySQL 估算的「该表在使用索引定位后，还需在引擎层保留多少比例的行」。它不是扫描比例，而是**索引命中后，仍需保留参与后续连接或返回的比例**。比如 filtered=10 表示：即使通过索引快速定位了 1000 行，最终也只留下约 100 行（1000 × 10%），其余 900 行得被丢弃——这说明索引的选择性弱，或者 WHERE 条件太宽泛。
常见误导是看到 type=ref 且 key 非空就认为“索引生效了”，但如果 filtered 只有 1 或 5，实际效果可能和全表扫描差不多，尤其当 rows 很大时（例如 rows=50000 × filtered=2 → 实际有效行仅约 1000，但引擎仍要处理 5 万行中间结果）。
什么时候该怀疑 filtered 值不准或不可信
filtered 是基于表级统计信息（ANALYZE TABLE 更新）估算的，不是实时采样结果。它容易失准的场景包括：
- 表刚批量导入大量数据，但没执行
ANALYZE TABLE，统计直方图过期 - 字段存在严重数据倾斜（例如
status字段 95% 是'ACTIVE'，5% 是其他值） - 条件含函数或表达式，如
WHERE DATE(create_time) = '2026-10-01'，优化器无法准确估算分布 - 联合索引中，只用了前缀列（如索引
(a,b,c)，查询只用了a = ?），filtered会高估后续列的过滤能力
如何用 filtered + rows 估算真实过滤量
不要单独看 filtered，必须和 rows 联合解读。MySQL 内部粗略按 rows × filtered / 100 推算该表最终输出行数（用于决定是否走嵌套循环、是否建临时表等）。实操中可手动验算：
例如执行 EXPLAIN SELECT * FROM users WHERE city = '杭州' AND age > 25; 得到：rows=8200，filtered=12.5 → 估算有效行 ≈ 8200 × 0.125 = 1025 行。如果实际返回远少于这个数（比如只有 30 行），说明 filtered 严重高估，优化器可能误判连接顺序或索引价值。
这时应检查：
- 该索引是否包含
city和age（联合索引顺序是否合理） -
city值分布是否均匀（SELECT COUNT(*), city FROM users GROUP BY city ORDER BY COUNT(*) DESC LIMIT 5;） - 是否因隐式类型转换导致索引失效（如
city是VARCHAR，但传入数字参数）
filtered 和 Extra 中 Using where 的关系常被忽略
当 Extra 出现 Using where，表示 Server 层还要对引擎返回的行做二次过滤；而 filtered 值越低，通常意味着 Using where 的开销越大——因为引擎给了太多“候选行”，Server 层得挨个判断。
对比两种情况：
✅ 理想：索引覆盖全部 WHERE 条件 → Extra=Using index，filtered 接近 100，rows 小
⚠️ 风险：索引只覆盖部分条件 → Extra=Using where; Using index，filtered 低于 20，且 rows 大 → 回表 + Server 过滤双重开销
❌ 危险：Extra=Using where 但 key 为 NULL → 全表扫描后 Server 层硬过滤，filtered 数值已无参考意义
