查看key的MVCC信息，还存在tikv_gc_safe_point 之前的版本

🪐 TiDB 技术问题
1

查看key的MVCC信息，还存在tikv_gc_safe_point 之前的版本
多久会被合并清理？
curl http://10.10.30.203:14583/mvcc/key/tidbcs/t29/8070450532247928834
{
“key”: “7480000000000064ED5F72F000000000000002”,
“region_id”: 529729,
“value”: {
“info”: {
“writes”: [
{
“start_ts”: 466915024358342657,
“commit_ts”: 466915024358342658,
“short_value”: “gAACAAAAAQIBAAUAAmwyMTI=”
},
{
“start_ts”: 466915009809612803,
“commit_ts”: 466915009809612804,
“short_value”: “gAACAAAAAQIBAAQAAmwyMQ==”
},
{
“start_ts”: 466623003924889608,
“commit_ts”: 466623003924889610,
“short_value”: “gAACAAAAAQIBAAMAAmwy”
}
]
}
}
}
select tidb_parse_tso(‘466623003924889610’);-- 2026-05-29 11:31:37.150000
tikv_gc_safe_point | 20260611-09:51:22.199 +0800

2

有可能存在大的事务，导致gc被阻塞。可以使用命令看看有没有正在执行中的sql：SELECT * from INFORMATION_SCHEMA.CLUSTER_PROCESSLIST

3

没有大事务，就是个测试表。

4

测试表写入量低，RocksDB 压缩（compaction）很少触发，旧 MVCC 版本就长期残留在文件里；

5

这个是有什么机制控制的么？ 会检测region的读写？读写高的在gc后才会真正触发compact的？

6

测试表读写少，RocksDB 压缩（compaction）未触发，GC 仅标记旧版本、不立即物理删除
GC 只清理逻辑版本，物理删除依赖压缩；Region 读写活跃时压缩更易触发，旧数据才会被彻底清除

7

MVCC的清理和compact是解耦的，没有强关联。
GC只负责标记删除。compact有自己的参数控制。
大概分两种：一种是mvcc的行数或比例超过参数值；第二种是L0的SST触发的compact；
8.5.4+版本参数由以下控制：

gc.auto-compaction

用于配置 TiKV 自动 compaction 的行为。

redundant-rows-threshold 从 v7.5.7 和 v8.5.4 版本开始引入

  • 触发 TiKV 自动 compaction 需要的冗余的 MVCC 数据行数，包含 RocksDB tombstone、TiKV stale versions 和 TiKV deletion tombstones。当冗余的 MVCC 数据行数达到此阈值，或这些行数的占比达到 redundant-rows-percent-threshold 时，TiKV 将触发自动 compaction。
  • 仅在开启 Compaction Filter 时生效。
  • 默认值：50000
  • 最小值：0
    等等参数。
8

无删除标记的旧 MVCC 版本，GC 不会主动删掉

9

TiKV 的 MVCC 多版本数据，GC safe point（GC 安全点） 是 GC 能往前清理旧版本的时间边界：时间戳早于这个 safe point 的 MVCC 旧版本，理论上都可以被 GC 回收；保留的是 safe point 之前最后一个有效写入版本，更早的历史版本都会被清理合并。

10

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。