[TiDB Usage Environment] Production Environment / Testing / PoC
[TiDB Version]
[Encountered Issues]
[Reproduction Path] What operations were performed to encounter the issue
[Issue Phenomenon and Impact]
TiDB supports optimistic transaction model, pessimistic transaction model, SI, REPEATABLE READ, READ COMMITTED. How should one choose in actual use?
[Attachment]
Please provide the version information of each component, such as cdc/tikv, which can be obtained by executing cdc version/tikv-server --version.
For general development, the default settings are fine. Higher isolation levels can easily lead to table locking, causing some operations to not function properly.
You can refer to these two articles. The snapshot read isolation level mainly addresses the phantom read problem, which requires waiting for locks during the prewrite phase of other transactions. If the other transaction is a large one, it may lead to significant lock conflicts. This is an issue with snapshot reads, but the advantage is that it only needs to obtain a timestamp at the beginning of the transaction. The RC isolation level does not have such read-write conflicts, but each statement within the transaction needs to obtain a timestamp, which incurs a cost in terms of timestamps. However, considering everything, a pessimistic lock + RC isolation level might be more effective.
For the implementation and principles of snapshot reads, you can refer to the following two articles:
|
username: alfred
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: 
|
username: