TiDB 组件 GC 原理及常见问题
内容提要
本文介绍了TiDB的垃圾回收（GC）机制及其实现原理和常见问题排查方法，包括计算GC safepoint、解析锁、连续范围数据删除和同步GC safepoint至集群其他组件。文章还讲述了定位GC leader、监控GC状态以及处理GC过程中的常见问题。
延伸解读
GC safepoint 的计算逻辑与数据安全
GC safepoint 是 TiDB 决定删除哪些旧版本数据的时间戳，其计算需综合 GC lifetime、未提交事务的最早开始时间以及外部服务（如 CDC/BR）所需的最旧快照。默认 GC lifetime 为 10 分钟，但若存在长时间未提交事务，safepoint 会被阻塞，直到事务结束或超过 tidb_gc_max_wait_time（默认 24 小时）。因此，调整 GC lifetime 或存在长事务时，需关注 safepoint 推进情况，避免误删仍需的数据。
Resolve locks 的必要性与性能影响
在删除旧版本前，必须清理 GC safepoint 之前事务残留的锁，否则可能导致读快照时无法确认事务状态，引发数据一致性问题。Resolve locks 会扫描所有 region 的锁，可能唤醒静默 region，导致 TiKV CPU 抖动。例如，一个 TiKV 维护 1 万个 region 时，GC 期间 CPU 开销可能从 1% 升至 10-15%。因此，在业务低峰期执行 GC 或调整并发参数可减轻影响。
Delete Ranges 的优化与适用场景
对于 DROP/TRUNCATE TABLE 等操作产生的连续范围数据，TiDB 通过 Delete Ranges 步骤直接物理删除，绕过逐版本清理，从而快速释放空间并降低对读写的影响。该步骤依赖系统表 mysql.gc_delete_range 记录删除时间，并在 GC 时调用 TiKV 的 unsafeDestroyRange 接口。若短期内需删除大量数据，此步骤可能耗时较长，但通常无需干预，耐心等待即可。
GC 状态监控与常见问题定位
定位 GC leader 可通过查询 mysql.tidb 中的 tikv_gc_leader_desc，并在对应 TiDB 日志中搜索 gc_worker 关键字。Grafana 的 TiKV Details -> GC 面板可观察 GC worker actions 和 safepoint 推进。若 GC 卡住，常见原因包括未提交事务、外部服务要求更早快照等，日志中会给出具体阻塞信息。根据日志提示排查并处理即可，多数情况符合预期。
Q&A
TiDB 的垃圾回收（GC）机制是如何工作的？
TiDB 的 GC 机制通过计算 GC safepoint、解析锁、删除连续范围数据和同步 GC safepoint 至集群其他组件来清理旧数据，减少性能影响。
什么是 GC safepoint，它的作用是什么？
GC safepoint 是一个时间戳，表示在此时间点之前的数据快照是安全的，GC 过程会根据这个时间戳来决定哪些旧版本数据可以被清理。
如何监控 TiDB 的 GC 状态？
可以通过 Grafana 监控 GC worker actions 和 GC safepoint 的推进情况来观察 TiDB 的 GC 状态。
GC leader 在 TiDB 中的角色是什么？
GC leader 是负责推动集群 GC 工作的角色，确保同一时刻只有一个 GC leader 来协调 GC 过程。
TiDB GC 过程中常见的问题有哪些？
常见问题包括 GC 卡住、未提交事务影响 GC 进程等，这些问题通常需要通过日志进行排查。
如何处理 GC safepoint 被卡住的情况？
可以检查当前集群中是否存在长时间运行且未提交的事务，或使用 PD 查看需要的最旧快照对应的 safepoint，以定位问题。
