图片 1

InnoDB意向锁和插入意向锁

 

事务锁管理

InnoDB
所有的事务锁对象都是挂在全局对象lock_sys上,同时每个事务对象上也维持了其拥有的事务锁,每个表对象(dict_table_t)上维持了构建在其上的表级锁对象。

如下图所示:

图片 1

 

This section describes lock types used by InnoDB.

Preface

作者: 淘宝阿里数据库组

* *

Predicate Locks for Spatial Indexes

InnoDB supports SPATIAL indexing of columns containing spatial
columns (see Section 11.5.8, “Optimizing Spatial
Analysis”
).

To handle locking for operations involving SPATIAL indexes, next-key
locking does not work well to
support REPEATABLE READ orSERIALIZABLE transaction
isolation levels. There is no absolute ordering concept in
multidimensional data, so it is not clear which is the “next” key.

To enable support of isolation levels for tables
with SPATIAL indexes, InnoDB uses predicate locks. A SPATIAL index
contains minimum bounding rectangle (MBR) values, so InnoDB enforces
consistent read on the index by setting a predicate lock on the MBR
value used for a query. Other transactions cannot insert or modify a row
that would match the query condition.

 

Next-Key Locks

A next-key lock is a combination of a record lock on the index record
and a gap lock on the gap before the index record.

InnoDB performs row-level locking in such a way that when it searches
or scans a table index, it sets shared or exclusive locks on the index
records it encounters. Thus, the row-level locks are actually
index-record locks. A next-key lock on an index record also affects
the “gap” before that index
record. That is, a next-key lock is an index-record lock plus a gap lock
on the gap preceding the index record. If one session has a shared or
exclusive lock on record R in an index, another session cannot insert
a new index record in the gap immediately before R in the index
order.

Suppose that an index contains the values 10, 11, 13, and 20. The
possible next-key locks for this index cover the following intervals,
where a round bracket denotes exclusion of the interval endpoint and a
square bracket denotes inclusion of the endpoint:

(negative infinity, 10]
(10, 11]
(11, 13]
(13, 20]
(20, positive infinity)

For the last interval, the next-key lock locks the gap above the largest
value in the index and the “supremum” pseudo-record having a value higher than any
value actually in the index. The supremum is not a real index record,
so, in effect, this next-key lock locks only the gap following the
largest index value.

By default, InnoDB operates
in REPEATABLE READ transaction
isolation level. In this case, InnoDB uses next-key locks for searches
and index scans, which prevents phantom rows (see Section 14.5.4,
“Phantom
Rows”
).

Transaction data for a next-key lock appears similar to the following
in SHOW ENGINE INNODB STATUS and InnoDB
monitor
 output:

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` 
trx id 10080 lock_mode X
Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 0: len 8; hex 73757072656d756d; asc supremum;;

Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     'O;;
 2: len 7; hex b60000019d0110; asc        ;;

 

Insert Intention Locks

An insert intention lock is a type of gap lock set
by INSERT operations
prior to row insertion. This lock signals the intent to insert in such a
way that multiple transactions inserting into the same index gap need
not wait for each other if they are not inserting at the same position
within the gap. Suppose that there are index records with values of 4
and 7. Separate transactions that attempt to insert values of 5 and 6,
respectively, each lock the gap between 4 and 7 with insert intention
locks prior to obtaining the exclusive lock on the inserted row, but do
not block each other because the rows are nonconflicting.

The following example demonstrates a transaction taking an insert
intention lock prior to obtaining an exclusive lock on the inserted
record. The example involves two clients, A and B.

Client A creates a table containing two index records (90 and 102) and
then starts a transaction that places an exclusive lock on index records
with an ID greater than 100. The exclusive lock includes a gap lock
before record 102:

mysql> CREATE TABLE child (id int(11) NOT NULL, PRIMARY KEY(id)) ENGINE=InnoDB;
mysql> INSERT INTO child (id) values (90),(102);

mysql> START TRANSACTION;
mysql> SELECT * FROM child WHERE id > 100 FOR UPDATE;
+-----+
| id  |
+-----+
| 102 |
+-----+

Client B begins a transaction to insert a record into the gap. The
transaction takes an insert intention lock while it waits to obtain an
exclusive lock.

mysql> START TRANSACTION;
mysql> INSERT INTO child (id) VALUES (101);

Transaction data for an insert intention lock appears similar to the
following
in SHOW ENGINE INNODB STATUS and InnoDB
monitor
output:

RECORD LOCKS space id 31 page no 3 n bits 72 index `PRIMARY` of table `test`.`child`
trx id 8731 lock_mode X locks gap before rec insert intention waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 80000066; asc    f;;
 1: len 6; hex 000000002215; asc     " ;;
 2: len 7; hex 9000000172011c; asc     r  ;;...
  1 //Session 1:
  2 zlm@192.168.56.100:3306 [zlm]>select @@global.innodb_status_output;
  3 +-------------------------------+
  4 | @@global.innodb_status_output |
  5 +-------------------------------+
  6 |                             1 |
  7 +-------------------------------+
  8 1 row in set (0.00 sec)
  9 
 10 zlm@192.168.56.100:3306 [zlm]>select @@autocommit;
 11 +--------------+
 12 | @@autocommit |
 13 +--------------+
 14 |            1 |
 15 +--------------+
 16 1 row in set (0.00 sec)
 17 
 18 zlm@192.168.56.100:3306 [zlm]>begin;select * from t where name = 'aaa' lock in share mode;
 19 Query OK, 0 rows affected (0.00 sec)
 20 
 21 +----+------+
 22 | id | name |
 23 +----+------+
 24 |  1 | aaa  |
 25 +----+------+
 26 1 row in set (0.00 sec)
 27 
 28 //Session 2:
 29 zlm@192.168.56.100:3306 [(none)]>select @@global.innodb_status_output_locks;
 30 +-------------------------------------+
 31 | @@global.innodb_status_output_locks |
 32 +-------------------------------------+
 33 |                                   1 |
 34 +-------------------------------------+
 35 1 row in set (0.00 sec)
 36 
 37 zlm@192.168.56.100:3306 [(none)]>select @@global.innodb_status_output;
 38 +-------------------------------+
 39 | @@global.innodb_status_output |
 40 +-------------------------------+
 41 |                             1 |
 42 +-------------------------------+
 43 1 row in set (0.00 sec)
 44 
 45 zlm@192.168.56.100:3306 [(none)]>select @@autocommit;
 46 +--------------+
 47 | @@autocommit |
 48 +--------------+
 49 |            1 |
 50 +--------------+
 51 1 row in set (0.00 sec)
 52 
 53 zlm@192.168.56.100:3306 [(none)]>begin;select * from t for update;
 54 Query OK, 0 rows affected (0.00 sec)
 55 
 56 ERROR 1046 (3D000): No database selected
 57 zlm@192.168.56.100:3306 [(none)]>begin;select * from zlm.t for update;
 58 Query OK, 0 rows affected (0.00 sec)
 59 
 60 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction //Wait for 50 seconds(by default) then becomes timeout.
 61 zlm@192.168.56.100:3306 [(none)]>
 62 
 63 //Check the lock information in error log.
 64 [root@zlm1 04:02:10 /data/mysql/mysql3306/data]
 65 #tail -f error.log 
 66 
 67 ...
 68 ------------
 69 TRANSACTIONS
 70 ------------
 71 Trx id counter 2996011
 72 Purge done for trx's n:o < 2996003 undo n:o < 0 state: running but idle
 73 History list length 12
 74 LIST OF TRANSACTIONS FOR EACH SESSION:
 75 ---TRANSACTION 2996010, ACTIVE 3 sec starting index read
 76 mysql tables in use 1, locked 1
 77 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
 78 MySQL thread id 244, OS thread handle 140311521974016, query id 9672 zlm1 192.168.56.100 zlm Sending data
 79 select * from zlm.t for update
 80 ------- TRX HAS BEEN WAITING 3 SEC FOR THIS LOCK TO BE GRANTED:
 81 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996010 lock_mode X waiting
 82 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 83  0: len 6; hex 000000000700; asc       ;;
 84  1: len 6; hex 0000002db708; asc    -  ;;
 85  2: len 7; hex a8000002610110; asc     a  ;;
 86  3: len 4; hex 80000001; asc     ;;
 87  4: len 10; hex 61616120202020202020; asc aaa       ;;
 88 
 89 ------------------
 90 TABLE LOCK table `zlm`.`t` trx id 2996010 lock mode IX
 91 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996010 lock_mode X waiting
 92 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 93  0: len 6; hex 000000000700; asc       ;;
 94  1: len 6; hex 0000002db708; asc    -  ;;
 95  2: len 7; hex a8000002610110; asc     a  ;;
 96  3: len 4; hex 80000001; asc     ;;
 97  4: len 10; hex 61616120202020202020; asc aaa       ;;
 98 
 99 ...
100 ----------------------------
101 END OF INNODB MONITOR OUTPUT
102 ============================
103 ^C
104 
105 //Only an "IX" intention lock and an "X" record lock were found.There's no "IS" intention lock any more.
106 //Intention locks between transactons does not block each other,they don't conflict.Therefore,when session 2 is gonna to get "X" lock(for update),the "IX" intention lock was generated and the "IS" intention in session 1 didn't appear.
107 //How about reversing the operations in session 1 and session 2?Let's see below.
108 
109 //Session 1:
110 zlm@192.168.56.100:3306 [zlm]>begin;select * from t for update;
111 Query OK, 0 rows affected (0.00 sec)
112 
113 +----+------+
114 | id | name |
115 +----+------+
116 |  1 | aaa  |
117 |  2 | bbb  |
118 |  4 | ccc  |
119 |  6 | fff  |
120 +----+------+
121 4 rows in set (0.00 sec)
122 
123 //Session 2:
124 zlm@192.168.56.100:3306 [(none)]>begin;select * from t where name = 'aaa' lock in share mode;
125 Query OK, 0 rows affected (0.00 sec)
126 
127 ERROR 1046 (3D000): No database selected
128 zlm@192.168.56.100:3306 [(none)]>begin;select * from zlm.t where name = 'aaa' lock in share mode;
129 Query OK, 0 rows affected (0.00 sec)
130 
131 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
132 zlm@192.168.56.100:3306 [(none)]>
133 
134 //Check the error log.
135 [root@zlm1 04:31:00 /data/mysql/mysql3306/data]
136 #tail -f error.log 
137 
138 ...
139 ------------
140 TRANSACTIONS
141 ------------
142 Trx id counter 2996012
143 Purge done for trx's n:o < 2996003 undo n:o < 0 state: running but idle
144 History list length 12
145 LIST OF TRANSACTIONS FOR EACH SESSION:
146 ---TRANSACTION 2996011, ACTIVE 26 sec
147 2 lock struct(s), heap size 1136, 5 row lock(s)
148 MySQL thread id 293, OS thread handle 140311415437056, query id 11463 zlm1 192.168.56.100 zlm
149 TABLE LOCK table `zlm`.`t` trx id 2996011 lock mode IX
150 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996011 lock_mode X
151 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
152  0: len 8; hex 73757072656d756d; asc supremum;;
153 
154 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
155  0: len 6; hex 000000000700; asc       ;;
156  1: len 6; hex 0000002db708; asc    -  ;;
157  2: len 7; hex a8000002610110; asc     a  ;;
158  3: len 4; hex 80000001; asc     ;;
159  4: len 10; hex 61616120202020202020; asc aaa       ;;
160 
161 Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
162  0: len 6; hex 000000000701; asc       ;;
163  1: len 6; hex 0000002db708; asc    -  ;;
164  2: len 7; hex a800000261011f; asc     a  ;;
165  3: len 4; hex 80000002; asc     ;;
166  4: len 10; hex 62626220202020202020; asc bbb       ;;
167 
168 Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
169  0: len 6; hex 000000000702; asc       ;;
170  1: len 6; hex 0000002db708; asc    -  ;;
171  2: len 7; hex a800000261012e; asc     a .;;
172  3: len 4; hex 80000004; asc     ;;
173  4: len 10; hex 63636320202020202020; asc ccc       ;;
174 
175 Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
176  0: len 6; hex 000000000703; asc       ;;
177  1: len 6; hex 0000002db721; asc    - !;;
178  2: len 7; hex 360000012c2a35; asc 6   ,*5;;
179  3: len 4; hex 80000006; asc     ;;
180  4: len 10; hex 66666620202020202020; asc fff       ;;
181  
182  ...
183 ----------------------------
184 END OF INNODB MONITOR OUTPUT
185 ============================
186 ^C
187 
188 //We've still get merely "IX" intention lock.The different is that there're four "X" record lock genrated by session 1 and they blocks the session 2 to hold shared read lock on those records,becuase "X" record locks confilct with both "X" and "S" record locks.Remember that we have no index key on column "name" and "select ... where name = 'aaa' lock in share mode;" mean to hold all the "S" record locks on the "name" column.

Shared and Exclusive Locks

InnoDB implements standard row-level locking where there are two types
of locks, shared (S)
locks
 and exclusive
(X)
locks
.

  • shared (S)
    lock
     permits
    the transaction that holds the lock to read a row.

  • An exclusive (X)
    lock
     permits
    the transaction that holds the lock to update or delete a row.

If transaction T1 holds a shared (S) lock on row r, then
requests from some distinct transaction T2 for a lock on row r are
handled as follows:

  • A request by T2 for an S lock can be granted immediately. As a
    result, both T1 and T2 hold an S lock on r.

  • A request by T2 for an X lock cannot be granted immediately.

If a transaction T1 holds an exclusive (X) lock on row r, a
request from some distinct transaction T2 for a lock of either type
on rcannot be granted immediately. Instead, transaction T2 has to
wait for transaction T1 to release its lock on row r.

 

 

  • *

Record Locks

A record lock is a lock on an index record. For
example, SELECT c1 FROM t WHERE c1 = 10 FOR UPDATE; prevents any other
transaction from inserting, updating, or deleting rows where the value
of t.c1 is 10.

Record locks always lock index records, even if a table is defined with
no indexes. For such cases, InnoDB creates a hidden clustered index
and uses this index for record locking. See Section 14.8.2.1,
“Clustered and Secondary
Indexes”
.

Transaction data for a record lock appears similar to the following
in SHOW ENGINE INNODB STATUS and InnoDB
monitor
 output:

RECORD LOCKS space id 58 page no 3 n bits 72 index `PRIMARY` of table `test`.`t` 
trx id 10078 lock_mode X locks rec but not gap
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
 0: len 4; hex 8000000a; asc     ;;
 1: len 6; hex 00000000274f; asc     'O;;
 2: len 7; hex b60000019d0110; asc        ;;

    Now we’ve known clearly about
intention locks,but what’s the insert intention locks?Are the intention
locks relevant with insert operations?Almost,it actually related to gap
lock generated by insert operation.It indicates that transactions of
insert do not need to wait for each other if they are not inserting at
same position within the gap when they later get the exclusive locks on
those inserted rows .

MYSQL原文链接  本文链接扩展  

 

AUTO-INC Locks

An AUTO-INC lock is a special table-level lock taken by transactions
inserting into tables with AUTO_INCREMENT columns. In the simplest
case, if one transaction is inserting values into the table, any other
transactions must wait to do their own inserts into that table, so that
rows inserted by the first transaction receive consecutive primary key
values.

The innodb_autoinc_lock_mode configuration
option controls the algorithm used for auto-increment locking. It allows
you to choose how to trade off between predictable sequences of
auto-increment values and maximum concurrency for insert operations.

For more information, see Section 14.8.1.5, “AUTO_INCREMENT Handling
in
InnoDB”
.

 

Gap Locks

A gap lock is a lock on a gap between index records, or a lock on the
gap before the first or after the last index record. For
example, SELECT c1 FROM t WHERE c1 BETWEEN 10 and 20 FOR UPDATE; prevents
other transactions from inserting a value of 15 into column t.c1,
whether or not there was already any such value in the column, because
the gaps between all existing values in the range are locked.

A gap might span a single index value, multiple index values, or even be
empty.

Gap locks are part of the tradeoff between performance and concurrency,
and are used in some transaction isolation levels and not others.

Gap locking is not needed for statements that lock rows using a unique
index to search for a unique row. (This does not include the case that
the search condition includes only some columns of a multiple-column
unique index; in that case, gap locking does occur.) For example, if
the id column has a unique index, the following statement uses only an
index-record lock for the row having id value 100 and it does not
matter whether other sessions insert rows in the preceding gap:

SELECT * FROM child WHERE id = 100;

If id is not indexed or has a nonunique index, the statement does lock
the preceding gap.

It is also worth noting here that conflicting locks can be held on a gap
by different transactions. For example, transaction A can hold a shared
gap lock (gap S-lock) on a gap while transaction B holds an exclusive
gap lock (gap X-lock) on the same gap. The reason conflicting gap locks
are allowed is that if a record is purged from an index, the gap locks
held on the record by different transactions must be merged.

Gap locks in InnoDB are “purely inhibitive”, which means they only stop other
transactions from inserting to the gap. They do not prevent different
transactions from taking gap locks on the same gap. Thus, a gap X-lock
has the same effect as a gap S-lock.

Gap locking can be disabled explicitly. This occurs if you change the
transaction isolation level
to READ COMMITTED or
enable
theinnodb_locks_unsafe_for_binlog system
variable (which is now deprecated). Under these circumstances, gap
locking is disabled for searches and index scans and is used only for
foreign-key constraint checking and duplicate-key checking.

There are also other effects of using
the READ COMMITTED isolation
level or
enabling innodb_locks_unsafe_for_binlog.
Record locks for nonmatching rows are released after MySQL has evaluated
the WHERE condition. For UPDATE statements, InnoDB does a “semi-consistent” read, such that it
returns the latest committed version to MySQL so that MySQL can
determine whether the row matches the WHERE condition of
the UPDATE.

  1 zlm@192.168.56.100:3306 [zlm]>set @@global.innodb_status_output_locks=on;
  2 Query OK, 0 rows affected (0.00 sec)
  3 
  4 zlm@192.168.56.100:3306 [zlm]>exit
  5 Bye
  6 
  7 [root@zlm1 03:44:23 /data/mysql/mysql3306/data]
  8 #mysql
  9 Welcome to the MySQL monitor.  Commands end with ; or \g.
 10 Your MySQL connection id is 217
 11 Server version: 5.7.21-log MySQL Community Server (GPL)
 12 
 13 Copyright (c) 2000, 2018, Oracle and/or its affiliates. All rights reserved.
 14 
 15 Oracle is a registered trademark of Oracle Corporation and/or its
 16 affiliates. Other names may be trademarks of their respective
 17 owners.
 18 
 19 Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 20 
 21 zlm@192.168.56.100:3306 [(none)]>select @@transaction_isolation;
 22 +-------------------------+
 23 | @@transaction_isolation |
 24 +-------------------------+
 25 | REPEATABLE-READ         |
 26 +-------------------------+
 27 1 row in set (0.00 sec)
 28 
 29 zlm@192.168.56.100:3306 [(none)]>select @@global.innodb_status_output_locks;
 30 +-------------------------------------+
 31 | @@global.innodb_status_output_locks |
 32 +-------------------------------------+
 33 |                                   1 |
 34 +-------------------------------------+
 35 1 row in set (0.00 sec)
 36 
 37 zlm@192.168.56.100:3306 [(none)]>select @@global.innodb_status_output;
 38 +-------------------------------+
 39 | @@global.innodb_status_output |
 40 +-------------------------------+
 41 |                             1 |
 42 +-------------------------------+
 43 1 row in set (0.00 sec)
 44 
 45 zlm@192.168.56.100:3306 [(none)]>select @@autocommit;
 46 +--------------+
 47 | @@autocommit |
 48 +--------------+
 49 |            1 |
 50 +--------------+
 51 1 row in set (0.00 sec)
 52 
 53 zlm@192.168.56.100:3306 [(none)]>use zlm
 54 Reading table information for completion of table and column names
 55 You can turn off this feature to get a quicker startup with -A
 56 
 57 Database changed
 58 zlm@192.168.56.100:3306 [zlm]>begin;select * from t where name = 'aaa' lock in share mode;
 59 Query OK, 0 rows affected (0.00 sec)
 60 
 61 +----+------+
 62 | id | name |
 63 +----+------+
 64 |  1 | aaa  |
 65 +----+------+
 66 1 row in set (0.00 sec)
 67 
 68 zlm@192.168.56.100:3306 [zlm]>select * from t for update;
 69 +----+------+
 70 | id | name |
 71 +----+------+
 72 |  1 | aaa  |
 73 |  2 | bbb  |
 74 |  4 | ccc  |
 75 |  6 | fff  |
 76 +----+------+
 77 4 rows in set (0.00 sec)
 78 
 79 [root@zlm1 03:42:09 /data/mysql/mysql3306/data]
 80 #tail -f error.log 
 81 
 82 ...
 83 ------------
 84 TRANSACTIONS
 85 ------------
 86 Trx id counter 2996010
 87 Purge done for trx's n:o < 2996003 undo n:o < 0 state: running but idle
 88 History list length 12
 89 LIST OF TRANSACTIONS FOR EACH SESSION:
 90 ---TRANSACTION 2996009, ACTIVE 29 sec
 91 4 lock struct(s), heap size 1136, 10 row lock(s)
 92 MySQL thread id 217, OS thread handle 140311415838464, query id 8738 zlm1 192.168.56.100 zlm
 93 TABLE LOCK table `zlm`.`t` trx id 2996009 lock mode IS //Here's an "IS" intention lock generated by "select ... lock in share mode;" operation.
 94 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996009 lock mode S //Here's a "S" shared lock of records.
 95 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 96  0: len 8; hex 73757072656d756d; asc supremum;;
 97 
 98 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 99  0: len 6; hex 000000000700; asc       ;;
100  1: len 6; hex 0000002db708; asc    -  ;;
101  2: len 7; hex a8000002610110; asc     a  ;;
102  3: len 4; hex 80000001; asc     ;;
103  4: len 10; hex 61616120202020202020; asc aaa       ;;
104 
105 Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
106  0: len 6; hex 000000000701; asc       ;;
107  1: len 6; hex 0000002db708; asc    -  ;;
108  2: len 7; hex a800000261011f; asc     a  ;;
109  3: len 4; hex 80000002; asc     ;;
110  4: len 10; hex 62626220202020202020; asc bbb       ;;
111 
112 Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
113  0: len 6; hex 000000000702; asc       ;;
114  1: len 6; hex 0000002db708; asc    -  ;;
115  2: len 7; hex a800000261012e; asc     a .;;
116  3: len 4; hex 80000004; asc     ;;
117  4: len 10; hex 63636320202020202020; asc ccc       ;;
118 
119 Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
120  0: len 6; hex 000000000703; asc       ;;
121  1: len 6; hex 0000002db721; asc    - !;;
122  2: len 7; hex 360000012c2a35; asc 6   ,*5;;
123  3: len 4; hex 80000006; asc     ;;
124  4: len 10; hex 66666620202020202020; asc fff       ;;
125 
126 TABLE LOCK table `zlm`.`t` trx id 2996009 lock mode IX //Here's an "IX" intertion lock generated by "select ... for update;" operation.
127 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996009 lock_mode X //Here's a "X" exclusive lock of records.
128 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
129  0: len 8; hex 73757072656d756d; asc supremum;;
130 
131 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
132  0: len 6; hex 000000000700; asc       ;;
133  1: len 6; hex 0000002db708; asc    -  ;;
134  2: len 7; hex a8000002610110; asc     a  ;;
135  3: len 4; hex 80000001; asc     ;;
136  4: len 10; hex 61616120202020202020; asc aaa       ;;
137 
138 Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
139  0: len 6; hex 000000000701; asc       ;;
140  1: len 6; hex 0000002db708; asc    -  ;;
141  2: len 7; hex a800000261011f; asc     a  ;;
142  3: len 4; hex 80000002; asc     ;;
143  4: len 10; hex 62626220202020202020; asc bbb       ;;
144 
145 Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
146  0: len 6; hex 000000000702; asc       ;;
147  1: len 6; hex 0000002db708; asc    -  ;;
148  2: len 7; hex a800000261012e; asc     a .;;
149  3: len 4; hex 80000004; asc     ;;
150  4: len 10; hex 63636320202020202020; asc ccc       ;;
151 
152 Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
153  0: len 6; hex 000000000703; asc       ;;
154  1: len 6; hex 0000002db721; asc    - !;;
155  2: len 7; hex 360000012c2a35; asc 6   ,*5;;
156  3: len 4; hex 80000006; asc     ;;
157  4: len 10; hex 66666620202020202020; asc fff       ;;
158 ...
159 
160 ----------------------------
161 END OF INNODB MONITOR OUTPUT
162 ============================
163 ^C
164 
165 //We've got an "IS" intention loc,an "IX" intention lock,four "S" locks and four "X" locks.
166 //Why does "slect ... where name = 'aaa' lock in share mode;" operation holds four "S" locks while we just specify one line?'cause "name" column does not has index key on it.
167 //Therefore,if we need to observe the intention locks.The variable of "innodb_status_output_locks" should be set "on".

Intention Locks

InnoDB supports multiple granularity
locking
 which permits coexistence of row-level locks and locks on
entire tables. To make locking at multiple granularity levels practical,
additional types of locks called intention
locks
 are
used. Intention locks are table-level locks in InnoDB that indicate
which type of lock (shared or exclusive) a transaction requires later
for a row in that table. There are two types of intention locks used
in InnoDB (assume that transaction T has requested a lock of the
indicated type on table t):

  • Intention
    shared
     (IS):
    Transaction T intends to set S locks on individual rows in
    table t.

  • Intention
    exclusive
     (IX):
    Transaction T intends to set X locks on those rows.

For
example, SELECT ... LOCK IN SHARE MODE sets
an IS lock
and SELECT ... FOR UPDATE sets
an IX lock.

The intention locking protocol is as follows:

  • Before a transaction can acquire an S lock on a row in
    table t, it must first acquire an IS or stronger lock on t.

  • Before a transaction can acquire an X lock on a row, it must
    first acquire an IX lock on t.

These rules can be conveniently summarized by means of the
following lock type compatibility
matrix
.

  X IX S IS
X Conflict Conflict Conflict Conflict
IX Conflict Compatible Conflict Compatible
S Conflict Conflict Compatible Compatible
IS Conflict Compatible Compatible Compatible

A lock is granted to a requesting transaction if it is compatible with
existing locks, but not if it conflicts with existing locks. A
transaction waits until the conflicting existing lock is released. If a
lock request conflicts with an existing lock and cannot be granted
because it would
cause deadlock,
an error occurs.

Thus, intention locks do not block anything except full table requests
(for example, LOCK TABLES ... WRITE). The main purpose
of IX and IS locks is to show that someone is locking a row, or
going to lock a row in the table.

Transaction data for an intention lock appears similar to the following
in SHOW ENGINE INNODB STATUS and InnoDB
monitor
output:

TABLE LOCK table `test`.`t` trx id 10080 lock mode IX
  1 //Session 1:
  2 zlm@192.168.56.100:3306 [(zlm)]>select @@transaction_isolation;
  3 +-------------------------+
  4 | @@transaction_isolation |
  5 +-------------------------+
  6 | REPEATABLE-READ         |
  7 +-------------------------+
  8 1 row in set (0.00 sec)
  9 
 10 zlm@192.168.56.100:3306 [zlm]>begin;select * from t for update;
 11 Query OK, 0 rows affected (0.00 sec)
 12 
 13 +----+------+
 14 | id | name |
 15 +----+------+
 16 |  1 | aaa  |
 17 |  2 | bbb  |
 18 |  4 | ccc  |
 19 |  6 | fff  |
 20 +----+------+
 21 4 rows in set (0.00 sec)
 22 
 23 //Session 2:
 24 zlm@192.168.56.100:3306 [(zlm)]>select @@transaction_isolation;
 25 +-------------------------+
 26 | @@transaction_isolation |
 27 +-------------------------+
 28 | REPEATABLE-READ         |
 29 +-------------------------+
 30 1 row in set (0.00 sec)
 31 
 32 zlm@192.168.56.100:3306 [(none)]>begin;insert into zlm.t values(5,'eee');
 33 Query OK, 0 rows affected (0.00 sec)
 34 
 35 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
 36 zlm@192.168.56.100:3306 [(none)]>
 37 
 38 //Check the error log for detail of locks.
 39 [root@zlm1 04:51:25 /data/mysql/mysql3306/data]
 40 #tail -f error.log 
 41 
 42 ...
 43 ------------
 44 TRANSACTIONS
 45 ------------
 46 Trx id counter 2996022
 47 Purge done for trx's n:o < 2996020 undo n:o < 0 state: running but idle
 48 History list length 15
 49 LIST OF TRANSACTIONS FOR EACH SESSION:
 50 ---TRANSACTION 2996021, ACTIVE 13 sec inserting
 51 mysql tables in use 1, locked 1
 52 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s) //The two lock structs were intention lock("IX") and insert intention lock.
 53 MySQL thread id 318, OS thread handle 140311522375424, query id 12700 zlm1 192.168.56.100 zlm update
 54 insert into zlm.t values(5,'eee')
 55 ------- TRX HAS BEEN WAITING 13 SEC FOR THIS LOCK TO BE GRANTED:
 56 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996021 lock_mode X insert intention waiting
 57 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 58  0: len 8; hex 73757072656d756d; asc supremum;; //Session 1 holds all "X" record locks of table "t".So it showed supremum what means the gap is infinite and no record can be inserted into the table at all.
 59 
 60 ------------------
 61 TABLE LOCK table `zlm`.`t` trx id 2996021 lock mode IX //The "IX" intention lock of session 2.
 62 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996021 lock_mode X insert intention waiting
 63 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 64  0: len 8; hex 73757072656d756d; asc supremum;;
 65 
 66 ---TRANSACTION 2996020, ACTIVE 255 sec
 67 2 lock struct(s), heap size 1136, 5 row lock(s)
 68 MySQL thread id 316, OS thread handle 140311522174720, query id 12450 zlm1 192.168.56.100 zlm
 69 TABLE LOCK table `zlm`.`t` trx id 2996020 lock mode IX //The "IX" intention lock of session 1.
 70 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996020 lock_mode X
 71 Record lock, heap no 1 PHYSICAL RECORD: n_fields 1; compact format; info bits 0
 72  0: len 8; hex 73757072656d756d; asc supremum;;
 73 
 74 Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 75  0: len 6; hex 000000000700; asc       ;;
 76  1: len 6; hex 0000002db708; asc    -  ;;
 77  2: len 7; hex a8000002610110; asc     a  ;;
 78  3: len 4; hex 80000001; asc     ;;
 79  4: len 10; hex 61616120202020202020; asc aaa       ;;
 80 
 81 Record lock, heap no 3 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 82  0: len 6; hex 000000000701; asc       ;;
 83  1: len 6; hex 0000002db708; asc    -  ;;
 84  2: len 7; hex a800000261011f; asc     a  ;;
 85  3: len 4; hex 80000002; asc     ;;
 86  4: len 10; hex 62626220202020202020; asc bbb       ;;
 87 
 88 Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 89  0: len 6; hex 000000000702; asc       ;;
 90  1: len 6; hex 0000002db708; asc    -  ;;
 91  2: len 7; hex a800000261012e; asc     a .;;
 92  3: len 4; hex 80000004; asc     ;;
 93  4: len 10; hex 63636320202020202020; asc ccc       ;;
 94 
 95 Record lock, heap no 5 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
 96  0: len 6; hex 000000000703; asc       ;;
 97  1: len 6; hex 0000002db721; asc    - !;;
 98  2: len 7; hex 360000012c2a35; asc 6   ,*5;;
 99  3: len 4; hex 80000006; asc     ;;
100  4: len 10; hex 66666620202020202020; asc fff       ;;
101  
102  ...
103 ----------------------------
104 END OF INNODB MONITOR OUTPUT
105 ============================
106 ^C
107 
108 //Session 2 meant to get an insert intention lock when it was executing "insert into xxx" but waited until timeout.
109 //Whatif we only lock a certain record,what will session do then?Let's see below.
110 
111 //Session 1:
112 zlm@192.168.56.100:3306 [zlm]>begin;select * from t where id=4 for update;
113 Query OK, 0 rows affected (0.00 sec)
114 
115 +----+------+
116 | id | name |
117 +----+------+
118 |  4 | ccc  |
119 +----+------+
120 1 row in set (0.00 sec)
121 
122 //Session 2:
123 zlm@192.168.56.100:3306 [(none)]>begin;insert into zlm.t values(3,'ccc');
124 ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction
125 zlm@192.168.56.100:3306 [(none)]>
126 
127 //Check error log again.
128 [root@zlm1 05:06:19 /data/mysql/mysql3306/data]
129 #tail -f error.log 
130 
131 ...
132 ------------
133 TRANSACTIONS
134 ------------
135 Trx id counter 2996025
136 Purge done for trx's n:o < 2996020 undo n:o < 0 state: running but idle
137 History list length 15
138 LIST OF TRANSACTIONS FOR EACH SESSION:
139 ---TRANSACTION 2996024, ACTIVE 9 sec inserting
140 mysql tables in use 1, locked 1
141 LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s), undo log entries 1
142 MySQL thread id 376, OS thread handle 140311521974016, query id 14398 zlm1 192.168.56.100 zlm update
143 insert into zlm.t values(3,'ccc')
144 ------- TRX HAS BEEN WAITING 9 SEC FOR THIS LOCK TO BE GRANTED:
145 RECORD LOCKS space id 175 page no 4 n bits 72 index id of table `zlm`.`t` trx id 2996024 lock_mode X locks gap before rec insert intention waiting
146 Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
147  0: len 4; hex 80000004; asc     ;;
148  1: len 6; hex 000000000702; asc       ;;
149 
150 ------------------
151 TABLE LOCK table `zlm`.`t` trx id 2996024 lock mode IX
152 RECORD LOCKS space id 175 page no 4 n bits 72 index id of table `zlm`.`t` trx id 2996024 lock_mode X locks gap before rec insert intention waiting
153 Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
154  0: len 4; hex 80000004; asc     ;;
155  1: len 6; hex 000000000702; asc       ;;
156 
157 ---TRANSACTION 2996023, ACTIVE 28 sec
158 4 lock struct(s), heap size 1136, 3 row lock(s)
159 MySQL thread id 374, OS thread handle 140311415437056, query id 14377 zlm1 192.168.56.100 zlm
160 TABLE LOCK table `zlm`.`t` trx id 2996023 lock mode IX
161 RECORD LOCKS space id 175 page no 4 n bits 72 index id of table `zlm`.`t` trx id 2996023 lock_mode X
162 Record lock, heap no 4 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
163  0: len 4; hex 80000004; asc     ;;
164  1: len 6; hex 000000000702; asc       ;;
165 
166 RECORD LOCKS space id 175 page no 3 n bits 72 index GEN_CLUST_INDEX of table `zlm`.`t` trx id 2996023 lock_mode X locks rec but not gap
167 Record lock, heap no 4 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
168  0: len 6; hex 000000000702; asc       ;;
169  1: len 6; hex 0000002db708; asc    -  ;;
170  2: len 7; hex a800000261012e; asc     a .;;
171  3: len 4; hex 80000004; asc     ;;
172  4: len 10; hex 63636320202020202020; asc ccc       ;;
173 
174 RECORD LOCKS space id 175 page no 4 n bits 72 index id of table `zlm`.`t` trx id 2996023 lock_mode X locks gap before rec
175 Record lock, heap no 5 PHYSICAL RECORD: n_fields 2; compact format; info bits 0
176  0: len 4; hex 80000006; asc     ;;
177  1: len 6; hex 000000000703; asc       ;;
178 
179 //The locks seem to be more and more complicated.
180 //Session 1(TRANSACTION 2996023) holded an "IX" intention lock,a "X" record lock,two gap locks.
181 //Session 2(TRANSACTION 2996024) asked for holded an "IX" intention lock and asked for an intert intention lock which was relevant with the gap before the record it meant to insert.The transaction of session 2 waited until timeout.

 

 1 zlm@192.168.56.100:3306 [zlm]>select @@transaction_isolation;
 2 +-------------------------+
 3 | @@transaction_isolation |
 4 +-------------------------+
 5 | REPEATABLE-READ         |
 6 +-------------------------+
 7 1 row in set (0.00 sec)
 8 
 9 zlm@192.168.56.100:3306 [zlm]>show variables like '%status%';
10 +----------------------------+-------+
11 | Variable_name              | Value |
12 +----------------------------+-------+
13 | innodb_status_output       | ON    | //If set "on",it prints innodb status into error log and refresh every 20s by default.
14 | innodb_status_output_locks | OFF   | //If set "off",there're no intention locks in result of "show engine innodb status;".
15 +----------------------------+-------+
16 2 rows in set (0.01 sec)
17 
18 zlm@192.168.56.100:3306 [(none)]>select @@autocommit;
19 +--------------+
20 | @@autocommit |
21 +--------------+
22 |            1 | //If does not specify "begin" or "start transaction" to explicitly generate a transaction,it commits after typing enter.
23 +--------------+
24 1 row in set (0.00 sec)
25 
26 zlm@192.168.56.100:3306 [zlm]>show create table t\G
27 *************************** 1. row ***************************
28        Table: t
29 Create Table: CREATE TABLE `t` (
30   `id` int(11) NOT NULL,
31   `name` char(10) DEFAULT NULL,
32   KEY `id` (`id`)
33 ) ENGINE=InnoDB DEFAULT CHARSET=utf8
34 1 row in set (0.01 sec)
35 
36 zlm@192.168.56.100:3306 [zlm]>begin;select * from t where name = 'aaa' lock in share mode;
37 Query OK, 0 rows affected (0.00 sec)
38 
39 +----+------+
40 | id | name |
41 +----+------+
42 |  1 | aaa  |
43 +----+------+
44 1 row in set (0.00 sec)
45 
46 zlm@192.168.56.100:3306 [zlm]>select * from t for update;
47 +----+------+
48 | id | name |
49 +----+------+
50 |  1 | aaa  |
51 |  2 | bbb  |
52 |  4 | ccc  |
53 |  6 | fff  |
54 +----+------+
55 4 rows in set (0.00 sec)
56 
57 [root@zlm1 03:41:54 /data/mysql/mysql3306/data]
58 #echo '' > error.log 
59 
60 [root@zlm1 03:42:04 /data/mysql/mysql3306/data]
61 #tail -f error.log 
62 
63 
64 ...
65 ------------
66 TRANSACTIONS
67 ------------
68 Trx id counter 2996009
69 Purge done for trx's n:o < 2996003 undo n:o < 0 state: running but idle
70 History list length 12
71 LIST OF TRANSACTIONS FOR EACH SESSION:
72 ---TRANSACTION 2996008, ACTIVE 83 sec
73 4 lock struct(s), heap size 1136, 10 row lock(s)
74 MySQL thread id 210, OS thread handle 140311521974016, query id 8335 zlm1 192.168.56.100 zlm
75 ...
76 
77 ----------------------------
78 END OF INNODB MONITOR OUTPUT
79 ============================
80 ^C
81 
82 //There're no intention locks at all.

*2. Intention locks test in
the same session with
“innodb_status_output_locks=on”.*

 

*Examples*

 

**2. I**nsert In***tention Locks***

  • *intention
    locks are table-level locks created by InnoDB automatically
    when we have intentions to modify a certain record(or some of
    relevant records) in these tables.*
  • The
    main effect of intention locks is to make InnoDB be more compatible
    in multidimensional lock granularity(both table-level and row-level
    locks).
  • It can
    simplify the mechanism in checking record locks of a certain
    table.For exmple,MySQL don’t need to retrieve the full table when a
    client(or session) is modifying
    (or going to modify) records in that
    table.

    **
  • The
    variables “innodb_status_output_locks” should be set “on”,if we
    want to see them in the output of “show engine innodb status”
    statement.
  • Insert
    intention locks is similar with intention locks but it’s merely
    relevant with those insert operations.
  X IX S IS
X Conflict Conflict Conflict Conflict
IX Conflict Compatible Conflict Compatible
S Conflict Conflict Compatible Compatible
IS Conflict Compatible Compatible Compatible

*Summary*

 

*1. Intention locks test **in
the same session **with
“innodb_status_output_locks=off”.***

Introduce

   What we can see is that intention
locks does not conflict themselves and always be compatible.In most
scenarios,Intention locks do not block other transactions except for
operation like “lock table … writ;”.The purpose of intention locks is
to tell Innodb that someone is gonna add a lock on those relevant
rows(for later reading or modifying) in a target table.

    Last
night one buddy in tech wechat group asked “what’s intention locks of
InnoDB?”Thus,I’m gonna say someting about it.As we all know,there’re
various types of lock in InnoDB engine such as record locks,gap
locks,next key locks and so forth.Intention locks is another kind of
granularity of lock of InnoDB.

   
There’re two kinds of intention locks in InnoDB:

 

 

 

***4. Inert intention
locks test.***

1.
Intention Locks

 

 

  • Intention
    shared lock(IS): It indicates that a transaction is setting
    (or
    going to set) a shared lock on several rows for shared query
    operations.
  • Intention
    exclusive lock(IX): It indicates that a transaction is 
    setting(or
    going to set) a exclusive lock on several rows for exclusive
    modification operations.**

   
Notice,any transaction who want to get row-level lock(shared or
exclusive lock) on a record in a table must get the intention locks
first.Generally speaking,S row-level lock is versus IS while X row-level
lock is versus IX.There conflict relationship shows below.

   
Intention locks of InnoDB are table-level locks.It’s generated to
indicate which type of lock relevant to a certain row in which the
transaction will involve(shared or exclusive lock).It seems like that
one guy is booking a ticket of the train to somewhere while the ticket
system broadcasts there’s a guy mean to ocuppy a seat of certain
compartment in the train.But it does not block the action of booking
ticket on the same train from another guy at the same time(another
intention lock).That is,intention locks does not block each other at all
only if you are modify the same row(booking the same seat).It’s the
effect of exclusive lock instead of intention lock.

**3. Intention locks test
between two sessions.**