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