# [Critical bug] TiKV doesn't GC the MVCC deletion versions and affects scan performance

[https://pingcap.feishu.cn/docs/doccnBSUZm67LxvfCprSihqj9Ys](https://pingcap.feishu.cn/docs/doccnBSUZm67LxvfCprSihqj9Ys)

[https://pingcap.feishu.cn/docs/doccnWvCPRTkabpG5CusardHYvP](https://pingcap.feishu.cn/docs/doccnWvCPRTkabpG5CusardHYvP)

[https://pingcap.feishu.cn/docs/doccnOYQnxdDoi6XEmxNQ6k2D2d](https://pingcap.feishu.cn/docs/doccnOYQnxdDoi6XEmxNQ6k2D2d)

## Issue

我们上一周发现了一个 Critical Bug，该 Bug 是由于 TiKV compaction filter GC 不能正常工作使得 MVCC deletion 版本没有被删除，进而影响了 scan 的性能。

### 问题现象

一些需要进行 TiKV scan 的查询持续性得慢（慢多少取决于实际负载如何）

EXPLAIN ANALYZE 的 scan detail 中显示 `key_skipped_count` 远远多于 `total_process_keys`

### 触发条件

负载中有比较多的 UPDATE/DELETE 命令

### 相关链接

[https://internal.pingcap.net/jira/browse/ONCALL-3777](https://internal.pingcap.net/jira/browse/ONCALL-3777)

[https://github.com/tikv/tikv/issues/11217](https://github.com/tikv/tikv/issues/11217)

[https://github.com/tikv/tikv/pull/11248](https://github.com/tikv/tikv/pull/11248)

## Root Cause

* TiKV compaction filter GC 会对 MVCC deletion 版本进行特殊处理以确保这个 deletion 版本之前的版本都被删除。当处理 deletion 版本时，TiKV 会获取这些 keys range 所覆盖的所有 region，但是忘记给这些 keys 去加 'z' 前缀导致获取 region 结果为空，进而那些 deletion 版本的处理被跳过。

* 在进行 scan 时，需要顺序遍历那些 deletion version 以找到下一个有效的 key，这些额外的工作使得 scan 性能下降。

## Diagnostic Steps

N/A

## Resolution

### 修复版本

v5.0.5

v5.1.3

v5.2.3

v5.3.0

## Workaround

设置 `gc.enable-compaction-filter: false` 以关闭 TiKV 的 compaction filter GC。注意：可能碰到另外的问题 [https://kb.pingcap.com/post/solutions/453](https://kb.pingcap.com/post/solutions/453)

升级到新版本。注意：对于在递增索引上的更新（比如时间索引），之前积累的未 GC 的数据在升级版本后可能无法及时回收，因为该段数据无新的写入无法触发 compaction 进而 GC。如有必要，可以考虑使用 tikv-ctl 手动触发 compact。