Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 普通（非事务）SQL读取需要获取TSO吗？
【TiDB Usage Environment】Production, Testing, Research
【TiDB Version】
【Encountered Problem】
【Reproduction Path】What operations were performed that led to the problem
【Problem Phenomenon and Impact】
【Attachments】
Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.
Isn’t a regular SQL also a transaction? The only difference is one is auto-commit and the other is manual commit. Both require obtaining TSO.
A regular select is also a transaction and requires obtaining a TSO.
Point queries should not require TSO, others require TSO.
If it’s similar to Oracle’s SCN, a regular select will also cause the SCN to increase.
At the beginning of a transaction, TiDB obtains a TSO as start_ts, and at the time of commit, it obtains a TSO as commit_ts. It relies on TSO to implement MVCC for transactions. For queries, MVCC requests TSO once, while for writes, it requests TSO twice. The TSO timestamp service ensures that timestamps are allocated in an increasing manner, and any timestamp obtained from a request will not be duplicated.
That means any query requires obtaining a TSO, because MVCC also relies on TSO.
Yes, otherwise how can consistency be achieved?
Any transaction (explicit or implicit) needs to obtain a TSO. Generally speaking, it starts with a start TSO, commits with a commit TSO, and pessimistic DML also has a for update TSO. The RC isolation level requires each SQL to obtain a TSO.
The RC isolation level requires each SQL to obtain a TSO. What about the RR isolation level?
It should have nothing to do with the isolation level; the transaction needs to obtain TSO when reading.
|
username: alfred
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: