INSERT sets an exclusive lock on the inserted row. This lock is an index-record lock, not a next-key lock (that is, there is no gap lock) and does not prevent other sessions from inserting into the gap before the inserted row.
insert 會對插入成功的行加上排他鎖。這個鎖不是索引記錄鎖，也不是next-key lock（更不是gap lock），不會阻止其他併發事務往這條記錄之前插入記錄。
Prior to inserting the row, a type of gap lock called an insert intention gap lock is set. 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 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.
在插入之前，設置了一個叫做insert intention gap lock（插入意向間隙鎖）的間隙鎖類型。此鎖表示插入這樣的意圖：即插入到同一索引間隙中的多個事務如果不在間隙內的同一位置插入，則不需要彼此等待。（個人理解，insert intention gap lock 不等於其他gap lock。不會阻塞）。假設有索引記錄的值爲4和7。當擁有4和7的這個insert intention locks在獲得x lock之前，兩個試圖插入5和6的事務不會相互阻塞對方，鎖不衝突。
If a duplicate-key error occurs, a shared lock on the duplicate index record is set. This use of a shared lock can result in deadlock should there be multiple sessions trying to insert the same row if another session already has an exclusive lock. This can occur if another session deletes the row. Suppose that an InnoDB table t1 has the following structure:
如果一個重複主鍵發生，那麼重複鍵設置在重複索引記錄上。（如果多事務insert 插入導致了duplicate-key ，那麼索引記錄被設置爲 shared lock 鎖）。在多併發情況下,如果一個session 已經有了x-lock，其他併發事務插入同一行記錄，那麼這個記錄上的s-lock將導致死鎖。 如下面例子
CREATE TABLE t1 (i INT, PRIMARY KEY (i)) ENGINE = InnoDB;
Now suppose that three sessions perform the following operations in order:
Session 1:
START TRANSACTION; INSERT INTO t1 VALUES(1);
Session 2:
START TRANSACTION; INSERT INTO t1 VALUES(1);
Session 3:
START TRANSACTION; INSERT INTO t1 VALUES(1);
Session 1:
ROLLBACK;
The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions 2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When session 1 rolls back, it releases its exclusive lock on the row and the queued shared lock requests for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an exclusive lock for the row because of the shared lock held by the other.
A similar situation occurs if the table already contains a row with key value 1 and three sessions perform the following operations in order:
Session 1:
START TRANSACTION; DELETE FROM t1 WHERE i = 1;
Session 2:
START TRANSACTION; INSERT INTO t1 VALUES(1);
Session 3:
START TRANSACTION; INSERT INTO t1 VALUES(1);
Session 1:
COMMIT;
The first operation by session 1 acquires an exclusive lock for the row. The operations by sessions 2 and 3 both result in a duplicate-key error and they both request a shared lock for the row. When session 1 commits, it releases its exclusive lock on the row and the queued shared lock requests for sessions 2 and 3 are granted. At this point, sessions 2 and 3 deadlock: Neither can acquire an exclusive lock for the row because of the shared lock held by the other.
上面的回話那個報出dead lock，由mysql本身調控。
