Disclaimer: This article is a blogger original article, shall not be reproduced without the bloggers allowed. https://blog.csdn.net/wrs120/article/details/91046701

MySQL knowledge about locks, see the blog post: https://blog.csdn.net/wrs120/article/details/86566879 , by the above description, know InnoDB storage engine supports row lock, mainly for the following InnoDB storage engine the row lock explain:

1. Lock Category

1.1 shared lock (S Lock)

It allows multiple transactions to read the same line data

1.2 exclusive lock (X Lock)

Allow transactions to delete or update the same data row

	X	S
x	Not compatible	Not compatible
s	Not compatible	compatible

InnoDB supports multi-granularity locking, allowing the lock on the lock on the table level and row level matters exist. In order to support operations on different granularity locking, InnoDB storage engine supports an additional lock mode, called intent lock . Intent lock means to lock objects into multiple levels, intent lock means want to lock in on a more granular. Intent lock to lock on the table level, but it means that the transaction is a read or write a row record, instead of the entire table, so no conflict between intent locks, check the real conflict in overtime row lock in to a row before locking, the first to give this table plus intent locks. Also intent is to simultaneously add table and row locks , is divided into:

Intention shared lock (IS Lock): Transaction want to get a few lines of a shared lock on the table
Intent exclusive locks (IX Lock): Transaction want to get a table row a few lines of lock

But InnoDB supports row-level locking, so intent lock is not going to block any requests except full table scan unexpected.

	IS	IX	S	X
IS	compatible	compatible	compatible	Not compatible
IX	compatible	compatible	Not compatible	Not compatible
S	compatible	Not compatible	compatible	Not compatible
X	Not compatible	Not compatible	Not compatible	Not compatible

1.3 intent locks

Why is there an intent lock that? ? ?
First example:

A locked transaction row in a table, so that the line can only read, can not write.
Transaction B then apply for a write lock on the entire table.
If the transaction B application is successful, then theoretically it will be able to modify any row of the table, which holds A row lock conflict.
The database is necessary to avoid such a conflict, that let application B is blocked until the release of A row lock.

Database to determine how this conflict it?

step1: to determine whether the table being used by other transactions with table locks table
step2: Each row in the table is determined whether a lock has been locked row

Note step2, such a method for determining the efficiency is not high, because of the need to traverse the entire table. Then there is the intention to lock . In the presence of intent locks A transaction must first apply for a shared intent lock on a table, after the successful application row lock line. In the presence of intent locks, the above determination can be changed

step1: unchanged
step2: find intent shared lock on the table, indicating that the table some rows are shared row locks locked, therefore, transaction B application form write lock will be blocked.

Note: The intention to apply the lock operation is complete database, that is, when the transaction row lock A row of application, the database will automatically lock the table before the start of the intention to apply, we do not need programmers use code to apply.

Summary: In order to facilitate detection of conflicts between the table-level locks and row-level locking, on the introduction of intent locks

1.4 Non-locking read consistency

InnoDB means to read the execution time of the current line data in the database by rows and versioning (MVCC) manner, such row being read DELETE or UPDATE operation, read operation at this time will not wait on the line X-lock release, a snapshot of the data, a snapshot of the data read lines but will go through the undo segment is done, undo data is used to roll back a transaction when in use, so long as implementation of the transaction would generate would certainly produce undo data, use snapshot data is no additional overhead, while a snapshot is not modified transaction, it would not have access to this data to perform a locking operation
InnoDB snapshot of each row may have multiple versions, so called multi-line version technology concurrency control in this technology become multi-version concurrency control (MVCC). In READ COMMITTED and REPEATABLE READ transaction isolation level, InnoDB uses consistent non-locking read, but the difference is in the READ COMMITTED transaction isolation level, snapshot data consistent non-locking read is always locked read the latest data snapshot copies of data; and in REPEATABLE rEAD transaction isolation level, snapshot data for non-locking read consistency always reads the start line when the data version Affairs

1.5 Consistency read lock

Explicit user needs to read the database to perform a locking operation in some cases operate to ensure data consistency logic, which can be achieved by locking the statement:

SELECT … FOR UPDATE（X锁）; SELECT … LOCK IN SHARE MODE（S锁）;

These statements can be used in a transaction, the transaction commit lock will automatically be released. Note that even rows are locked so explicitly, but other matters consistent non-locking read is to read a version of the snapshot data.

1.6 Growth and self-locking

Since the primary key for growth, InnoDB uses a special table lock mechanism Auto-inc locking, improve insert performance, but the lock is not released until after a transaction is completed, but released immediately after the completion of the self-growth values into the sql

1.7 foreign key and lock

For a foreign key column, if not explicitly added to the column index, the InnoDB automatically an index is added thereto, to avoid lock table. In need of foreign keys you will first need to insert or update records in the parent table SELECT, SELECT can not be used at this time is consistent non-locking read of the way, because it may result in inconsistent data problems at this time essentially using SELECT ... lOCK iN SHARE MODE, namely S will automatically add a lock to prevent the transaction execution in the row is deleted or modified, this also shows that the index is useful to add foreign key necessity.

2. The lock algorithm

2.1 Record Lock

Row locks, record locks on a single line, the algorithm always to lock the index record , if InnoDB storage engine not provided with any index table when creating, this time using an implicit primary key lock

2.2 Gap Lock

Gap lock, a lock range, but does not contain the records themselves

2.3 Next-Key Lock

Temporary lock that combines the Record Lock and Gap Lock, InnoDB row of the query are using this lock, but when when the index is a unique index, Next-Key Lock downgraded Record Lock for the
Next-Key Lock READ things in REPEATABLE under isolation level to solve the Phantom problem phantom read problems (Phantom problem refers to the same thing, the same two consecutive execution of SQL statements can lead to different results, the second of SQL may return before there is no line), certain Note that phantom read means to read the line does not exist, and not have to change the same data, illustrates why the Next-Key Lock solves the phantom read problem, the first transaction isolation level set to rEAD COMMITTED:

time	Session 1	Session 2
1	set session tx_isolation='READ-OMMITTED'
2	begin;
3	select * from t where a>2 for update 返回 a:4
4		begin;
5		insert into t select 4;
6		commit;
7	select * from t where a>2 for update 返回a:4 a:5	insert into t select 4;

A transaction can be found in the emergence of phantom reads, a more than a second reading: 5 this data. But the transaction isolation level is set to REPEATABLE READ, does not appear to celebrate, because the execution select * from where a> 2 for locked (2, + ∞) when the update, this range has been added x lock, when the second of further affairs perform insert 5 x lock can not be obtained, it can only be blocked.

InnoDB storage engine, for the Insert operation, checks the next record insert record is locked, if already locked, the query is not allowed.

3. Lock problem

Although the lock to achieve a transaction isolation requirements, so that the transaction can be complicated work, but there are some potential problems. Lock will bring the following three questions:

3.1 dirty read

Other data read uncommitted transactions, in violation of the requirements of database transaction isolation, this problem will not set transaction isolation level Read Uncommitted level will be able to solve this problem

3.2 Non-repeatable read

Read many times in a transaction to the same data set, but the results are not the same as reading. This problem occurs in Read Committed, the transaction isolation level to Read Repeatable use of Next-key Lock solve this problem
the data is read dirty read uncommitted, non-repeatable read is to read data has been submitted, but in violation of the database transactional consistency requirements

Lost 3.3 update on the logic

4. Deadlock

4.1 concept

Phenomenon refers to two or more transactions in the implementation process, due to competition for resources caused by a wait of each other

4.2 deadlock detection and solution

Timeout: set a threshold value, wait time exceeds this threshold, one of the transactions to be rolled back, so that another transaction can continue to run, but there is a problem, when the time-out firms accounted for the weight is relatively large, such as transactional operations update time may be more than many, many lines, taking up more undo log, roll back the transaction time relatively speaking another transaction
FIG waiting wait-for graph, loop detecting whether there is deadlock proof, depth-first algorithm versions before 1.2, 1.2 deadlock detection optimized, non-recursive recursive manner, the amount of rollback lowermost undo affairs

InnoDB storage engine does not roll back most of the error exception, except for the deadlock. When they find the deadlock, InnoDB will immediately roll back a transaction

5. Lock escalation

There is a lock escalation SQL SERVER databases, but InnoDB storage engine, lock escalation does not exist. Because it is not generating a row lock according to each record, on the contrary, according to each of access to each page lock transaction management using mode bitmap . 3,000,000 has a table of data pages, each page data 100, a total of 300 million records, if at this time the whole table updates the lock information for each page stores robe accounted for 30 bytes, then the object is the only 90MB memory, this situation does not occur, a lock occupies 10 bytes, all the locks on memory occupancy 3GB

[Lock] MySQL InnoDB storage engine

Article Directory