TiKV 没有单独的 GC 机制，GC 的触发依赖于 TiDB gc-worker 运行。
TiKV 收到 TiDB 发送的的 GC 命令（包含 SafePoint）后扫描当前 Region 的所有 key，然后对每个 Key 执行 GC 操作，即 SafePoint 之前只保留最后一次提交的数据。缺点是删除也是写入，需等待 compaction 运行后数据才真正删除。另外 GC 过程要占用系统资源，对正常事务的运行产生影响。
TiKV 在 3.0.6 版本开始支持 GC 流控，可通过配置 gc.max-write-bytes-per-sec 限制 GC worker 每秒数据写入量，降低对正常请求的影响，0 为关闭该功能。该配置可通过 tikv-ctl 动态修改
tikv-ctl --host=ip:port modify-tikv-config -m server -n gc.max_write_bytes_per_sec -v 10MB
Resolve Locks 这一步的任务即对 safe point 之前的锁进行清理。即如果一个锁对应的 Primary 已经提交，那么该锁也应该被提交；反之，则应该回滚。而如果 Primary 仍然是上锁的状态（没有提交也没有回滚），则应当将该事务视为超时失败而回滚。
Resolve Locks 的执行方式是由 GC leader 对所有的 Region 发送请求扫描过期的锁，并对扫到的锁查询 Primary 的状态，再发送请求对其进行提交或回滚。这个过程默认会并行地执行，并发数量默认与 TiKV 节点个数相同。
实际遇到要清理的锁的话，是调用 RocksDB 的 delete 接口，写入一个删除标记。
判断 Resolve Locks 操作的数量可以通过 TiKV-Details → gRPC → gRPC message count 中的 kv_scan_lock 请求数量来判断，kv_scan_lock 请求只会由 GC 导致，resolve_lock 操作可以通过 gRPC message count 中的 kv_resolve_lock 数量判断，但是因为正常查询也会产生 kv_resolve_lock 操作，所以该指标并不完全等同于 GC 产生的 resolve lock 操作。
在执行 DROP TABLE/INDEX 等操作时，会有大量连续的数据被删除。如果对每个 key 都进行删除操作、再对每个 key 进行 GC 的话，那么执行效率和空间回收速度都可能非常的低下。事实上，这种时候 TiDB 并不会对每个 key 进行删除操作，而是将这些待删除的区间及删除操作的时间戳记录下来。Delete Ranges 会将这些时间戳在 safe point 之前的区间进行快速的物理删除。
判断 Delete Ranges 操作的数量可以通过 TiKV-Details → gRPC → gRPC message count 中的 kv_delete_range 和 unsafe_destroy_range 请求来判断。
这一步即删除所有 key 的过期版本。为了保证 safe point 之后的任何时间戳都具有一致的快照，这一步删除 safe point 之前提交的数据，但是会对每个 key 保留 safe point 前的最后一次写入（除非最后一次写入是删除）。
在进行这一步时，TiDB 只需要将 safe point 发送给 PD，即可结束整轮 GC。TiKV 会自行检测到 safe point 发生了更新，会对当前节点上所有作为 Region leader 进行 GC。与此同时，GC leader 可以继续触发下一轮 GC。
Do GC 阶段，实际的操作是 TiKV 去扫描所有的 region ，如果发现 key 的 tso 信息早于 SafePoint 点了，那就调用 RocksDB 的 delete 接口，打一个删除标记。等待后续 Compaction 的时候回收空间。扫描所有 region 这一步有一点优化是，扫描的时候会根据 sst 上的元信息初步判断是否有较多的历史数据，进而来判断是否是可以跳过的。
每个 key 的版本个数，如果 GC 保留时间设置的越长，这个数值可能会越大，查询的时候会需要扫描更多的 MVCC 版本数据后获取到实际数据，影响查询速度。
GC 删除掉的每个 key 的版本数量
显示 TiKV 的 GC worker 执行的任务。这些任务分为 GC 任务和 UnsafeDestroyRange 任务。以 region 为粒度的。具体的指标有：
记录的是各种任务耗时的统计。通常在秒级别、偶尔出现十几秒的 task 都是正常的。如果持续耗时几十秒甚至分钟级别就可能有问题。
记录的是 GC 在 write cf 中进行的各种具体的读操作的统计。这个与应用操作导致的 get/next/seek 操作是区分开的。各种指标表示不同方式扫描 key ，数量是包含扫描的所有 key（包括新老 key）
TiDB GC Worker 的不同 action 的个数。只包括 Resolve Locks 和 Delete Ranges 两个阶段。具体的指标有：
TiDB 执行 GC 花费的时间
GC 删除旧版本的执行速度，单位为 keys/s
不用关注，看 TiKV Auto GC Progress 监控即可。
记录的是 TiDB 侧进行 Resolve Locks 的粗略进度，值为 Region 的数量。因为在 TiKV 面板不方便去 region 的总数，所以难以以百分比方式进行展示。
TiKV-Details → GC → TiKV Auto GC Progress
TiKV 自行进行分布式 GC 的阶段的粗略进度。分 TiKV 节点显示每台 TiKV 的进度，通过将已扫描的 Region 数量与该 TiKV 节点上 Region 总数相除的方式计算粗略的百分比。如果 GC 运行过快（比如在一个新建的几乎为空的集群上），该指标可能显示不出来。
注：如果在一轮 GC 运行过程中（如进行到 30% 时）TiKV 获取到了更新的 safepoint，下一轮 GC 则可能停止在上一轮更新 safepoint 时的进度（即下一次 GC 进度达到 30% 时停止）
每台 TiKV 当前自行 GC 时所使用的 SafePoint ，该 SafePoint 由每台 TiKV 定期从 PD 取得。
tikv_gc_life_time 的设置值
tikv_gc_run_interval 的设置值
