One, the deadlock problem
Reason: A user A accesses table A (locks table A), and then accesses table B; another user B accesses table B (locks table B), and then attempts to access table A; then user A is due to user B Table B has been locked, and it must wait for user B to release table B before it can continue. Similarly, user B has to wait for user A to release table A before it can continue. This deadlock occurs.
Lock type : exclusive lock (X lock) and shared lock (S lock).
The so-called exclusive lock (X lock) is that when transaction T adds X lock to data A, only transaction T is allowed to read and modify data A.
The so-called shared lock (S lock) is that when transaction T adds S lock to data A, other transactions can only add S lock to data A , but cannot add X lock, until T releases the S lock on A.
If transaction T pairs Data object A adds an S lock, then T can read A, but cannot update (the S lock is therefore also called a read lock). Before T releases the S lock on A, other transactions can add A to A. S lock, but X lock cannot be added, so that A can be read, but A cannot be updated.
Two, the plan
Solution:
This kind of deadlock is relatively common and is caused by a bug in the program. There is no other way except to adjust the logic of the program. Analyze the logic of the program carefully. For multi-table operations in the database, try to process them in the same order , and try to avoid locking two resources at the same time. For example, when operating two tables, A and B, they are always processed in the order of A and B. , When two resources must be locked at the same time, it is necessary to ensure that the resources should be locked in the same order at any time.
Three, other locks
MySQL storage engines use three types (levels) of locking mechanisms: table-level locking, row-level locking, and page-level locking
1. Table-level locking ( table-level )
Table-level locking is the most granular locking mechanism among MySQL storage engines. The biggest feature of the locking mechanism is that the implementation logic is very simple, and the negative impact of the system is minimal. So the speed of acquiring and releasing locks is very fast. Since the table-level lock will lock the entire table at one time, it can avoid the deadlock problem that plagues us.
Of course, the biggest negative impact brought by the large lock granularity is that the probability of contention for locked resources will also be the highest, resulting in a large discount. Some non-transactional storage engines such as MyISAM , MEMORY , and CSV
are mainly used for table-level locking .
2. Row-level lock ( row-level ) The
biggest feature of row-level lock is that the granularity of the locked object is very small, and it is also the smallest granularity of the lock realized by major database management software at present. Because the lock granularity is very small, the probability of contention for locked resources is also the smallest, which can give the application as much concurrent processing capacity as possible and improve the overall performance of some high-concurrency application systems.
Although it can have greater advantages in concurrent processing capabilities, row-level locking also brings a lot of drawbacks. Because the granularity of locked resources is very small, there are more things to do to acquire and release the lock each time, and the consumption is naturally greater. In addition, row-level locking is also the most prone to deadlock.
The main use of row-level locking is the InnoDB storage engine.
3. Page-level locking ( page-level )
Page-level locking is a unique locking level in MySQL , and it is not too common in other database management software. The feature of page-level locking is that the granularity of locking is between row-level locking and table-level locking. Therefore, the resource overhead required to obtain the lock and the concurrent processing capabilities that can be provided are also between the above two. In addition, page-level locking is the same as row-level locking, and deadlock occurs.
Summary of locks:
Table-level locks: low overhead and fast locking; no deadlocks; large locking granularity, the highest probability of lock conflicts, and the lowest concurrency;
row-level locks: high overhead and slow locking; deadlocks will occur; locking granularity The smallest, the lowest probability of lock conflicts, and the highest degree of concurrency;
page locks: overhead and lock time are between table locks and row locks; deadlocks will occur; locking granularity is between table locks and row locks, and concurrent The degree is average.
Applicability:
From the perspective of locks, table-level locks are more suitable for applications that focus on queries and only a small amount of data is updated based on index conditions, such as Web applications; while row-level locks are more suitable for a large number of concurrent updates based on index conditions. Different data, and concurrent query applications, such as some online transaction processing ( OLTP ) systems.
Good article recommendations on MySQL lock processing: