delete操作的时候，tidb具体是操作了什么

🪐 TiDB 技术问题
1

【 TiDB 使用环境】调研
【 TiDB 版本】v5.4.1
【遇到的问题】tidb在处理delete语句的时候，在底层的过程是什么，rocksdb raft和rocksdb kv具体的处理过程能不能解答下
【复现路径】做过哪些操作出现的问题
【问题现象及影响】

【附件】

请提供各个组件的 version 信息，如 cdc/tikv，可通过执行 cdc version/tikv-server --version 获取。

2

delete操作可认为也是向rocksdb中追加新的KV数据，其Key与要删除的KV数据的Key相同，Value是KTypeDeletion。

Raft层面的流程大概是：
1、Leader将delete操作转换为一条Raft Log，Raft Log中包含了Region ID、Raft Log ID和具体的日志内容
2、Append：Leader将Raft Log持久化到本地RocksDB(raftdb)中
3、Replicate：Leader将Raft Log复制到Followers进行同步， Followers接收到Raft Log后，会持久化到本地RocksDB(raftdb)中，并反馈Leader同步成功
4、Committed：当Leader收到多数派节点(包含Leader自己)Append成功的消息后，Leader认为这条Raft Log提交成功
5、Apply：将raftdb中的Raft log取出来，应用到kvdb中

RocksDB接收到写入的这条KV数据后，会先写入memtable，然后经过Immutable memtable刷到磁盘上的SST文件中，在RocksDB执行某次compaction的过程中，删除操作才会真正执行

2 个赞
3

那在compaction之前，如果有对这张表的查询，tikv读数据的时候也会读一遍这些已删除的数据，是这样吗

4

读操作会先读内存中的Block Cache、Memtable和Immutable Memtable，再去磁盘上读SST文件，从Level 0逐层往下找。按照这个路径，在compaction之前，读操作会先读到delete操作写入的KV数据，便知道这行数据已经被删除了，就不用返回了

5

谢谢，讲的很清晰

6

请教一下，对于delete操作，判断数据是否存在的动作是在Append Raft Log之前，还是在Apply时执行呢？

8

该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。