通过 TiDB MVCC API 查询到的数据版本是存在，实际 TiDB GC 的操作会将 safepoint 存到 PD 端，在 TiDB 侧可以视为已经 GC 完成了。但是实际 TiKV 会根据内部任务触发逻辑向 PD Sever 索要 safepoint ，然后根据 safepoint 再将旧的 MVCC 通过 Compaction 任务开始删除旧版本的 MVCC。所以这个是预期的情况。可以理解为删除旧版本的操作 TiDB 和 TiKV 共同完成以后，才视为删除。所以通过 API 查询看到 mvcc 没有清理，是预期的。
另外，因为每个 Region group 的 peer 都在不同 TiKV 实例，TiKV 实例的 GC 任务是异步的，所以可能有的旧 MVCC 版本已经清理，但是有的 peer 的旧版本还没有删除，没有办法保证已经比较的 safepoint 之前的快照是一致的。所以通常这里的旧版本的 MVCC 是保证一致性的。
Compaction Filter 开启后，gc 效率会比原来的高，是因为 Compactoin filter 承担部分之前 GC 单线程的任务操作，放在 TiKV 这一侧进行异步处理，这样可以让更多的 TIKV 实例到 gc_key 的操作中，加快处理速度。