# [KB]关于 TiDB 后台周期性读取 mysql.stats_fm_sketch-内部表导致查询延迟抖动

## Issue

应用查询量不大但耗时波动大（几十毫秒到几秒之间）， 即时查询几千条数据，耗时也在 0.01s~2.75s 之间波动

## Root Cause

1. 在 TiDB 5.0 开发过程中进行了分区表 dynamic pruning 优化和对应的统计信息重构工作，在这个工作中，引入了 @@tidb_partition_prune_mode = “dynamic” 的支持，并且在 mysql.stats_fm_sketch 中为每个表维护了 fm-sketch 数据，每次 analyze 后都会在该表中新增数据。

2. dynamic pruning 的优化和对应的统计信息重构并没有在 5.0 中发布出去，mysql.stats_fm_sketch 的垃圾回收机制也还没有完成，导致过期的 fm-sketch 数据不会被清除，该表会随着不停的 analyze 插入大量无用记录，数据量越来越大，导致 TiDB 后台周期性（默认情况下 3 秒一次）读取该表时占用的资源越来越多，最终影响用户的业务查询，使其延迟上升或抖动。

## Diagnostic Steps

1. 监控发现网卡监控发现带宽几乎被打满

2. Dashboard 慢查询中出现

    ```sql 
    SELECT value FROM mysql`.`stats_fm_sketch`WHERE`table_id`= ? AND`is_index`= ? AND`hist_id`= ?`
    ```

3. 执行 SELECT count(\*) FROM mysql.stats_fm_sketch 发现数据量非常大，有可能达到十几万

## Resolution

1. Workaround: 确保 @@tidb_partition_prune_mode 的值为 “static” 设置脚本，执行 delete 语句定期清空 mysql.stats_fm_sketch 中的数据：delete \* from mysql.stats_fm_sketch

2. 升级到 v5.0.2 及之后版本修复

3. 修复 PR ：[https://github.com/pingcap/tidb/pull/24357](https://github.com/pingcap/tidb/pull/24357)