TiDB事务何时触发Percolator的Prewrite呢?

【TiDB 版本】
5.0

【问题描述】
在学习TiDB事务模型时遇到一些问题,请原谅我比较小白,有些是基础问题。

下图是 TiDB in action一书中对事务部分的描述:https://book.tidb.io/session1/chapter6/optimistic-txn.html,这部分有一张图如下:

可以看到这里示意TiDB是在客户端提交SQL Commit时才会发起Percolator Prewrite的。我奇怪的点在于

  • 在SQL的事务过程中产生的Update并不会去底层TiKV执行吗?这些修改是否会导致TiDB的内存占用过高?

我个人设想的一种实现是,客户端发起BEGIN时,TiDB从tso获取timestamp,然后整个事务中涉及的Update都可以直接在收到客户端发来的事务语句时进行Prewrite,直到客户端发起Commit,TiDB发起Percolator的Commit操作。

为何没有采取这种方式呢?


若提问为性能优化、故障排查类问题,请下载脚本运行。终端输出的打印结果,请务必全选并复制粘贴上传。

可以先看下这个文章,包含悲观事务,要考虑冲突,重试等。你考虑的是只有一个sql吗?
https://docs.pingcap.com/zh/tidb/stable/optimistic-transaction#优缺点分析

我觉得TiDB目前的做法和我设想的做法之间的一个重要差异是:我的做法对某个KV的lock持有的时间和用户的事务周期相关,可能会阻塞其他事务的读写。

btw:只考虑一个SQL是什么意思呢?差别是?

和你的想法差不多,如果一直持有,单事务感觉影响不大,如果有其他事务就可能阻塞,影响比较大。没法并发的感觉。