【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
tidb 删除一条数据，tikv里面是怎么存储的呀
Key_delete → Value ?
，有没有人知道原理呀，分享一下
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
，有没有人知道原理呀，分享一下
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【附件：截图/日志/监控】
TiDB底层使用的是TiKV来存储数据，而TiKV使用的是LSM tree这种数据结构，它是一种append only模型，也就是说所有对数据的变更都体现在追加上。当删除一条数据时，实际上是将该数据的key标记为删除状态，而不是直接将其从磁盘中删除。这个被标记为删除状态的key会在后续的GC过程中被清理掉。因此，删除一条数据的实际操作是将该数据的key插入到TiKV中，并将其value设置为空。这个操作会生成一个Key_delete，对应的value为空。
key是row_id吗
在 TiDB 中，数据的 key 不是 row_id，而是由表的主键和索引组成的。TiDB 中的数据是以行的形式存储的，每一行数据都有一个唯一的主键，主键的值可以是任意类型，包括整数、字符串等。在 TiDB 中，主键和索引都是以 B+ 树的形式存储的，每个节点都包含多个 key-value 对，其中 key 是主键或索引的值，value 是指向数据行的指针。当 TiDB 执行查询操作时，会根据查询条件在 B+ 树上进行查找，找到对应的 key-value 对，然后根据指针找到对应的数据行。因此，TiDB 中的数据 key 不是 row_id，而是由主键和索引组成的。
如果你对源码比较感兴趣，你可以看看：
这是个持续学习的过程，如果你感兴趣一定要坚持一直学，一直看。
我理解删除的时候
key是
tablePrefix{TableID}_recordPrefixSep{RowID}delete{时间}
这个怎么理解都对， 
但是要符合 rocksDB compaction filter 或者 compaction 处理过程的语义…
TiDB使用基于Percolator的事务模型，将一行数据抽象为default、write 和 lock 3 个 CF(column family)存储，其中:
- default CF存储的真正数据
${key}_${start_ts} --> ${value} - write CF存储数据的版本信息，commit_ts代表一行记录的真正版本
${key}_${commit_ts}-->${start_ts} - lock CF存放锁信息,提交中的事务会加lock，包含primary lock的位置
${key}-->${start_ts,primary_key,..etc}
1 个赞
1 个赞
region层面，tikv会追加一天已删除的记录。
lsm层面，在分裂或合并时，会把已删除的数据从物理上都删除。
将该数据的key标记为删除状态
追加，变成多版本，然后gc吧