线上一张千万级记录表，因业务归档需求执行大范围 DELETE 删除过期数据，查询表内已无过期数据，但监控中 TiKV 磁盘容量没有下降，多次等待数天空间仍未自动释放，集群无磁盘满告警，GC 相关参数保持默认。
旧版本数据、墓碑标记会先留存，等待 GC 清理过期快照；
RocksDB 分层 LSM 树结构，低层旧 SST 文件不会即时合并删除，只有 Compaction 压实后才会真正回收磁盘；
默认 GC 窗口、合并节奏保守，大批量删除后仅等数天很难自动释放大量空间。
delete操作，由于mvcc机制，会导致磁盘储存不降反升，只有region compaction后才会释放空间，所以如果表中数据不需要，可以使用truncate 命令，这样gc后就释放了，要不就只能手动compaction
可以先找到对应表的部分region，手工compact看看空间是否会释放。
其次适当调整如下参数触发自动的compact：
gc.auto-compaction
用于配置 TiKV 自动 compaction 的行为。
check-interval 从 v7.5.7 和 v8.5.4 版本开始引入
- TiKV 检查是否需要触发自动 compaction 的时间间隔。在此时间段内，满足自动 compaction 条件的 Region 会按优先级进行处理。当到达此间隔时，TiKV 会重新扫描 Region 信息并重新计算优先级。
- 默认值：
"300s"
tombstone-num-threshold 从 v7.5.7 和 v8.5.4 版本开始引入
- 触发 TiKV 自动 compaction 需要的 RocksDB tombstone 个数。当 tombstone 数量达到此阈值，或 tombstone 所占比例达到
tombstone-percent-threshold时，TiKV 将触发自动 compaction。 - 仅在关闭 Compaction Filter 时生效。
- 默认值：
10000 - 最小值：
0
tombstone-percent-threshold 从 v7.5.7 和 v8.5.4 版本开始引入
- 触发 TiKV 自动 compaction 需要的 RocksDB tombstone 所占比例。当 tombstone 所占比例达到此阈值，或 tombstone 数量达到
tombstone-num-threshold时，TiKV 将触发自动 compaction。 - 仅在关闭 Compaction Filter 时生效。
- 默认值：
30 - 最小值：
0 - 最大值：
100
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
redundant-rows-percent-threshold 从 v7.5.7 和 v8.5.4 版本开始引入
- 触发 TiKV 自动 compaction 需要的冗余的 MVCC 数据行数所占比例。冗余数据包含 RocksDB tombstone、TiKV stale versions 和 TiKV deletion tombstones。当冗余的 MVCC 数据行数达到
redundant-rows-threshold，或这些行数的占比达到redundant-rows-percent-threshold时，TiKV 将触发自动 compaction。 - 仅在开启 Compaction Filter 时生效。
- 默认值：
20 - 最小值：
0 - 最大值：
100
bottommost-level-force 从 v7.5.7 和 v8.5.4 版本开始引入
- 控制是否强制对 RocksDB 最底层文件进行 compaction。
- 默认值：
true
mvcc-read-aware-enabled 从 v8.5.6 版本开始引入
- 控制是否启用 MVCC-read-aware compaction。启用后，TiKV 会跟踪读取请求期间扫描的 MVCC 版本数量，并利用这些信息优先对 MVCC 读取放大率高的 Region 进行 compaction。这可以降低在扫描期间遇到大量过期版本的热点 Region 的读延迟。
- 默认值：
false
mvcc-scan-threshold 从 v8.5.6 版本开始引入
- 将 Region 标记为 compaction 候选所需的每个读请求扫描的最小 MVCC 版本数量。此配置项仅在
mvcc-read-aware-enabled设置为true时生效。 - 默认值：
1000 - 最小值：
0
mvcc-read-weight 从 v8.5.6 版本开始引入
- 计算 Region 的 compaction 优先级得分时，应用于 MVCC 读取活动的权重倍数。较高的数值会提高 MVCC 读放大在整体评估中的权重，相对于其他 compaction 触发因素（例如 tombstone 密度）占比更大。该配置项仅在
mvcc-read-aware-enabled设置为true时生效。 - 默认值：
3.0 - 最小值：
0.0
Delete 仅标记数据删除，需等待MVCC GC清理、Region Merge回收空 Region；可手动触发 GC、加速 Region 合并。
你这个 TiKV 磁盘占用居高不下的问题，是 TiDB MVCC 机制下删除数据后未立即清理旧版本导致的：DELETE 操作只会给数据打上墓碑标记，真正的空间释放需要依赖 TiKV 的 GC 和 RocksDB 后台 compaction 流程。建议先确认 GC 已正常推进，通过 ADMIN SHOW TIDB_GC; 查看 safe point 时间，确保它已更新到 DELETE 执行时间之后；再手动触发一次 compaction，对目标表执行 ALTER TABLE <表名> FORCE 或直接发起 COMPACT TABLE <表名>; 主动触发 RocksDB 合并与清理，加速墓碑数据回收；同时可以检查是否存在长时间运行的事务或快照，它们会阻止 GC 清理旧版本，另外对于大批量删除的场景，更推荐用 DELETE ... LIMIT 分批执行，或改用 DROP PARTITION/TRUNCATE 这类直接回收空间的方式替代大范围 DELETE，避免大量墓碑数据堆积。
你等了多久，默认参数下delete释放空间大概需要几天时间
空间回收基于MVCC GC策略，GC worker定期清理过期版本。
某个TiKV宕机时间长会导致safepoint停滞。
此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。