Remember the Lock wait timeout on the line once
The scene
The error message is shown in the figure, Lock wait timeout exceeded. The first time I encountered it, my colleagues tried to solve this problem by increasing the innodb_lock_wait_timeout parameter to 100s (the default is 50s), and the situation has improved. But the good times didn't last long, and the exception was thrown again later, showing that the previous solution was not perfect. After studying mysql-related courses in depth ( 45 lectures on MYSQL combat is strongly recommended ), I have a solution to this problem.
analysis
| innodb_deadlock_detect (deadlock detection) | innodb_lock_wait_timeout (default 50s) |
|---|---|
| on (enabled by default) | Take effect |
| of | invalid |
There are two possibilities for the exception of Lock wait timeout
- Normal lock wait
The basis for determining the lock waiting caused by deadlock is to check whether the database parameter innodb_deadlock_detect is in the open state. If it is in the open state, the exception thrown when a deadlock occurs must be an exception similar to this: deadlock when... So, if it is dead Lock detection is turned on, then the exception will not be caused by deadlock waiting. If deadlock detection is turned off, then it is a normal lock wait. There must be a long transaction that takes up the lock and has not been released for a long time. . Here are solutions for these two abnormal scenarios.
Normal lock wait
The lock acquisition timeout caused by this scenario must correspond to a long transaction. The solution is to shorten the entire process from locking to unlocking.
- Adjust sql execution familiarity, put the added, deleted and modified sql to the end
- If there are multiple additions, deletions, and changes to the SQL, put the most concurrent operation to the end
- Optimize the code to shorten the time from begin to commit
Deadlock
- Shorten the entire process from locking to unlocking ( solution to normal lock waiting )
- Turn on deadlock detection and try again after the program catches an exception (similar to CAS lock, fast failure + retry). The disadvantage is that deadlock detection will consume CPU. If InnoDB has a large number of transaction threads, it will cause CPU 100% to be processed per second. Few things
- Turn off deadlock detection, set innodb_lock_wait_timeout, and try again after catching the exception. The disadvantage is that the exception is thrown after waiting for a period of time, the response is too slow, and the business is lossy
- Control the amount of concurrency of transactions (through client or middleware control)
- Sub-database and sub-table to reduce conflicts