Hi，小伙伴们~ 如果我们在 TiKV 中删除了同一前缀下的大量 key，再去做前缀搜索的话，是不是性能有较大的降低？
因为我理解的是，TiKV 下面的存储层用的是 RocksDB，而 RocksDB 的删除只是插入一条 Delete 的记录，并不是真正的去删除 key，导致即使一个前缀下的所有 key 都删除光了，那么拿这个前缀去搜索的时候，也会遍历这个前缀下的所有已经删除的 key，详见 RocksDB issue #5265.
如果 TiKV 没有这个问题，那么是做了哪些优化呢？由于本人对 TiKV 实现并不是很熟悉，希望大家能提供一些思路或建议，非常感谢~
有优化，但是优化得有限，参考下血案，基本上能解答你的疑问了
但是有一点，裸tikv 和 tidb的架构在处理数据上还是有很大区别的
非常感谢你的回答~ 我还有点疑问，仅仅针对 RocksDB 这层，除了手动触发 CompactRange，是否还有其他优化？（我在相关资料文档并没有找到）
特别是针对被删了的 key 还在 memtables 中并没有被 flush 到 SST 时，这时候也是会增加 scan 的时长，针对这方面，上层有做什么优化吗？
我记得之前 full table scan 的时候，不会跳过这些 被删除的 keys，后来在 seek keys 的策略上做了个调整，好像有个 issue 吧，最后做了版本的修复，具体从哪个版本做的修复，我忘记了 
然后还是建议考虑最佳实践中提供的方式，来操作数据的删除，避坑～
你把gc时间调整到10分钟
此话题已在最后回复的 1 分钟后被自动关闭。不再允许新回复。