看官方博客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的操作，就是打了标记删除的。就是说在读的阶段过滤了。
期待大佬有文章讲清楚。
一致性读，打了删除标记的