High Lock Contention: Significant Slow SQL Execution Time in the Prewrite Phase

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 锁冲突很多。大量慢sqlPrewrite 阶段耗时高

| username: 路在何chu

[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

| username: 路在何chu | Original post link

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?

| username: TIDB-Learner | Original post link

Self Q&A, :joy: The new version definitely has many optimizations.

| username: 路在何chu | Original post link

Conduct some research and see how much better the results are.

| username: xfworld | Original post link

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.

| username: yulei7633 | Original post link

This version is too old. The versions I’ve worked with start from v5.0.0.

| username: DBAER | Original post link

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.

| username: 路在何chu | Original post link

They are performing a large number of updates simultaneously modifying the same row.

| username: 路在何chu | Original post link

I don’t dare to change this recklessly.

| username: zhaokede | Original post link

This still needs to be resolved at the business level.
Why are a large number of updates simultaneously modifying the same row of data?

| username: DBAER | Original post link

This clearly has business logic issues and the design is unreasonable.

| username: TiDBer_RjzUpGDL | Original post link

Upgrade it.

| username: TiDBer_JUi6UvZm | Original post link

What is the use case? TiDB is not suitable for scenarios like flash sales, the region can’t handle it.

| username: TiDBer_JUi6UvZm | Original post link

Additionally, the version is indeed a bit old. Try testing with a new version.

| username: paulli | Original post link

First, check the business logic for lock conflicts.

| username: Jack-li | Original post link

Upgrading to a new version might bring improvements.

| username: Jellybean | Original post link

The business design is unreasonable if multiple concurrent accesses to a single row of data occur. Consider optimizing the access method.

| username: lemonade010 | Original post link

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.

| username: dockerfile | Original post link

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.