Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.
Original topic: 锁冲突很多。大量慢sqlPrewrite 阶段耗时高
[TiDB Usage Environment] Production environment 4014
[Reproduction Path] What operations were performed when the problem occurred
A large number of concurrent updates to a single record
[Encountered Problem: Problem Phenomenon and Impact]
Caused CPU to increase, database to slow down. Many lock conflicts
Would upgrading the version alleviate this issue? In the new version, lock information is written to memory, which is much more efficient than writing to disk, right?
Self Q&A,
The new version definitely has many optimizations.
Conduct some research and see how much better the results are.
Yes, the key is 2PC, which has been optimized to 1PC, improving the efficiency of transaction execution.
If upgrading the version is not an option, you can consider using optimistic locking as a way to optimize.
This version is too old. The versions I’ve worked with start from v5.0.0.
It might be better. In version 6, the pessimistic lock is in the memory of the Region leader, but the main thing is to resolve the SQL logic to avoid lock conflicts. Split large transactions.
They are performing a large number of updates simultaneously modifying the same row.
I don’t dare to change this recklessly.
This still needs to be resolved at the business level.
Why are a large number of updates simultaneously modifying the same row of data?
This clearly has business logic issues and the design is unreasonable.
What is the use case? TiDB is not suitable for scenarios like flash sales, the region can’t handle it.
Additionally, the version is indeed a bit old. Try testing with a new version.
First, check the business logic for lock conflicts.
Upgrading to a new version might bring improvements.
The business design is unreasonable if multiple concurrent accesses to a single row of data occur. Consider optimizing the access method.
We used to have a business system like this, with a large number of updates to the same data. The final solution was still to adjust the business logic.
Upgrading to V7.5.X won’t cure all issues, but at least 90% of the slow performance problems will disappear. You don’t need to know the reason.