看官方博客DML操作都是在事务的本地buffer中的，那delete也是针对buffer的吗，在commit之前不会真的去kv上删除，那delete完后再select，不是还会把刚才删除的那条数据从kv读上来吗，实际操作并没有出现这种情况，这个是怎么解决的呢？
建议看一下分布式事务的实现，以及MVCC，tidb保证了数据的一致性读
事务内delete 会很慢的 建议用跑批模式删除
delete本身也是插入一个kv,delete完后再select，select时搜索tikv就能发现原来这个key有个delete记录，知道被删除
你说的delete也是插入kv，那commit前这个kv是插入到事务的buffer里还是直接插到tikv了
哪篇博客？
一致性，不会读取到删除的数据
关于事务的啊
删不是真删，只是做个删除标记， 如果没事务还未提交， 其他进程肯定可以查到该数据。如果事务提交了。其他进程的事务在该删除事务提交前提交的，可以读到 ，反之读不到了。
mvcc（快照读）。事务的ACID。
tidb 分布式读写原理、时间戳、内存、日志的管理机制。共勉。
扫kv的时候会跳过，有时间戳和删除标记的。你explain会有skip的执行计划。
事务一致性
事务删除会很慢
事务内删太慢了，而且还不会立即释放空间，一般只做逻辑删。
你在执行计划中会看到skip的操作，就是打了标记删除的。就是说在读的阶段过滤了。
commit的时候会按照lsmtree的方式写日志，删除操作也是写入新的日志，只有做合并的时候才会真的清除历史数据。
TiDB 使用 MVCC 来处理并发读写。当执行 DELETE 操作时，它实际上是为被删除的行创建了一个新版本，标记为已删除。之后的 SELECT 操作会根据事务的可见性规则来读取数据，通常不会看到已删除的版本。
你可以看看这个文章，commit前，这个kv是在cache中。
另外tidb不支持READ-UNCOMMITTED。所以写入缓存中的这部分数据不用担心有其他线程需要访问。
DELETE操作是在本地缓冲区中进行的，提交之前不会直接影响 KV 存储。- 提交时，所有操作会原子性地应用到 KV 存储。
- 由于使用了快照隔离和 MVCC 机制，读操作会读取事务开始时的快照，确保数据的一致性。
1 个赞