This article is published by the official account [Developing Pigeon]! Welcome to follow! ! !
Old Rules-Sister Town House:
One. Two ways to handle concurrent transactions
(1) Write-to-write situation
In the write-write situation, the dirty write problem will occur. Any isolation level does not allow this problem to occur. When multiple uncommitted transactions make changes to a record one after another, they need to be queued for execution. The queuing process is through adding The lock is realized. The lock is essentially a structure in memory. When a transaction wants to change this record, first check whether there is a lock structure associated with this record in the memory. If not, a lock structure will be generated in the memory. Associated.
There are a lot of information in the lock structure, the most important are two, one is trx, which indicates which transaction the lock structure is associated with, and the other is ix_waiting, which indicates whether the current transaction is waiting. Not all locking operations need to generate a corresponding lock structure, and sometimes the "implicit lock" method is used to protect records.
(2) Read-write situation
In the case of reading, there will be dirty reading, non-repeatable reading, and phantom reading problems. How to avoid these problems? There are two options.
1. Use MVCC for read operation and lock for write operation
MVCC finds the record version that meets the conditions by generating a ReadView, that is, a snapshot is generated when the ReadView is generated, and the query statement (read operation) can only query the changes made by the submitted firm before the snapshot. For write operations, it must be a change to the latest version of the record. The historical version of the read record does not conflict with the latest version of the change record. That is, when MVCC is used, the read-write operation does not conflict.
2. Both read and write operations are locked
If there are some business scenarios that do not allow reading the old version of the record, but the latest version of the record must be read every time, then the read operation needs to be locked.
Obviously, with the MVCC method, the read-write operation does not conflict, and the performance is higher; with the locking method, both read and write operations need to be executed in a queue, which affects performance.
(3) Consistent reading
The read operation performed by the transaction using MVCC is called consistent read, and other transactions can freely modify the records in the table.
(Four) lock read
1. Shared locks and exclusive locks
Shared lock: S lock, when a transaction reads a record, it needs to acquire the S lock of the record first, and other transactions can also acquire the S lock;
exclusive lock: X lock, exclusive lock, the transaction needs to change a record first Acquire the X lock of the record, other transactions cannot obtain the X lock or S lock of the record;
2. Lock Read
The reading method that locks the record before reading it is called locked read. There are two special SELECT statements that support locked read:
(1) Add S lock to the read record
SELECT … LOCK IN SHARE MODE;
(2) Add X lock to the read record
SELECT … FOR UPDATE;
3. Write operation
（1） DELETE
Locate the position of the record in the B+ tree, obtain the X lock of the record, and execute the delete mark operation.
（2） UPDATE
Locate and obtain X lock.
（3） INSERT
A newly inserted record is protected by an implicit lock, and there is no need to generate a lock structure in memory.
two. Multi-granularity lock
(1) Row lock and table lock
1. Row Lock
Lock a record, granular training.
2. Table lock
To lock a table, the granularity is coarser. Table locks can also be divided into S locks and X locks. For S locks, other transactions can still obtain S locks for the table or S locks recorded in the table, but still cannot obtain X locks for tables and records. For the X lock of the table, nothing else can be done.
(2) Intention lock
1. Intention sharing lock
IS lock, when the transaction prepares to add S lock on a record, it needs to add an IS lock at the table level first.
2. Intent exclusive lock
IX lock, when the transaction prepares to add an X lock on a record, it needs to add an IX lock on the table level first.
Both IS and IX locks are only used when S locks or X locks are added to the table. They are used to quickly read whether any records in the current table are locked, avoiding the use of traversal to determine. When you want to add an S lock to a table, first check if there is an IX lock. If not, you can add an S lock. There is no need to check IS locks, because there are IS locks, you can also add S locks to the table. When adding an X lock to a table, it is necessary to determine whether there is an IS lock or an IX lock. Only when both locks are released can an X lock be added.
three. Row locks and table locks in MySQL
(1) Locks in InnoDB
1. Table-level S lock X lock
When executing SELECT, INSERT, DELETE, UPDATE statements on a table, InnoDB will not add table-level S locks or X locks for this table. When some DDL statements that change the table structure are executed on a table, other transactions are concurrently executing queries on this table, and the statement is blocked when writing statements. This is achieved through the metadata lock (MDL) in the server layer. Table-level S locks and X locks in InnoDB do not have much effect and may be used in recovery.
2. Table level AUTO-INC lock
Add the AUTO_INCREMENT attribute to a column of the table, and then insert the record without specifying the value of the column, the column is automatically incremented. The auto-increment of this column can be achieved in two ways:
(1) AUTO-INC lock
Add a table-level AUTO-INC lock when executing the insert statement, and assign an incremental value to the auto-increment column of each record to be inserted. After the statement is executed, the AUTO-INC lock is released, so that other transactions All insert statements will block to ensure that the incremental value assigned in a statement is continuous. The scope of this lock is a single insert statement.
(2) Lightweight lock
Acquire the lock and release the lock after the value of the column is generated, without waiting for the execution of the entire insert statement. If you can determine how many records to insert before inserting, use lightweight locks to avoid locking the entire table.
3. Row-level lock
（1） Record Lock
Record lock, which only locks one record, is divided into X lock and S lock.
（2） Gap Lock
MySQL can solve the phenomenon of phantom reading to a large extent under the repeatable read isolation level. It can be solved by MVCC or locking. However, when locking, when the transaction performs the first read operation, those phantom records are If it does not exist, we cannot add normal record locks to these records. The gap lock can solve this problem. When a gap lock is added to a record, it means that other transactions are not allowed to insert new records in the gap before the record, which can prevent the insertion of phantom records.
（3） next-key lock
It not only locks a record, but also prevents other transactions from inserting new records in the gap in front of the record. This type of record is called a next-key lock, which is a combination of a serious record lock and a gap lock.
（4） Insert Intention Lock
When a transaction inserts a record, it needs to determine whether the insertion position has been locked by other transactions. If there is, it needs to wait. When waiting, a lock structure is also generated in the memory, which is called the insertion intention lock. Great effect.
(5) Implicit lock
Generally, the execution of INSERT statement does not need to generate a lock structure in memory, but records without locks can easily be acquired by other transactions X lock or S lock, which will cause dirty read or dirty write problems. At this time, the problem can be solved by transaction id, which is equivalent to implicit lock. First, help the current transaction generate a lock structure, then generate a lock structure for itself, and enter the waiting state.
For clustered index records, the trx_id hidden column records the transaction id of the record. When other transactions want to add S lock or X lock to the record, they will check whether the transaction id has been committed. If it has been committed, read it normally. Take; otherwise, help the transaction to create a lock structure for X locks, instead of creating a lock structure by itself, and wait for the state.
For secondary index records, there is no trx_id column. There is an attribute in the Page Header that indicates the largest transaction id that makes changes to the page. If the attribute is less than the current smallest active transaction id, it means that all modified transactions are committed. Up.
4. The memory structure of the lock
It is impossible to create a lock structure for every record. The same transaction can be placed in a lock structure, and the locked records on the same page can be placed in a lock structure. The type of lock is the same. Into a lock structure.
four. View transaction lock status
(1) information_schema database
In the information_schema system database, there are several tables related to transactions and locks:
1. INNODB_TRX
Stores the transaction information currently being executed by InnoDB.
2. INNODB_LOCKS
Some lock information is recorded. If a transaction is waiting for a lock, the lock information is recorded. If a lock blocks other transactions, the lock information is recorded.
（二） SHOW ENGINE INNODB STATUS
Get the lock status of each transaction in the current system.
Fives. Deadlock
When a deadlock occurs, InnoDB will roll back a transaction to release the lock acquired by the transaction. We need to find out those statements that have deadlocked, and change the lock order by optimizing the statement, or create a suitable index to change the lock The process needs to be analyzed through the deadlock log to locate the deadlock statement.