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.
翻译：插入一行之前,一种间隙锁叫做插入意向锁的锁被设置。这把锁以这种方式标志这插入的意向：如果多个事务插入到相同的索引间隙的不同的位置时不需要相互等待。假设有值为4和7的索引记录。尝试插入值为5和6的独立事务，在获得插入行的排他锁之前，使用插入意图锁锁定4和7之间的间隙，但不会相互阻塞，因为行不冲突。
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:
翻译：如果出现重复键错误，则在重复索引记录上设置共享锁。如果有多个会话试图插入同一行，而另一个会话已经有排他锁，那么使用共享锁会导致死锁。如果另一个会话删除了该行，就会发生这种情况。假设InnoDB表t1的结构如下:
Now suppose that three sessions perform the following operations in order:
翻译：现在假设有三个会话按顺序执行以下操作:
Session 1:
Session 2:
Session 3:
Session 1:
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.
翻译：会话1的第一个操作为该行获取排他锁。会话2和会话3的操作都会导致重复键错误，并且它们都请求该行的共享锁。当会话1回滚时，它释放该行上的独占锁，并授予会话2和3的排队共享锁请求。此时，会话2和3死锁:由于另一方持有共享锁，这两个会话都不能获得该行的排他锁。
A similar situation occurs if the table already contains a row with key value 1 and three sessions perform the following operations in order:
翻译：如果表中已经包含键值为1的行，并且三个会话按顺序执行以下操作，则会出现类似的情况:
Session 1:
Session 2:
Session 3:
Session 1:
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.
翻译：会话1的第一个操作为该行获取排他锁。会话2和会话3的操作都会导致重复键错误，并且它们都请求该行的共享锁。当会话1提交时，它释放该行上的独占锁，并授予会话2和3的排队共享锁请求。此时，会话2和3死锁:由于另一方持有共享锁，这两个会话都不能获得该行的排他锁。
INSERT ... ON DUPLICATE KEY UPDATE differs from a simple INSERT in that an exclusive lock rather than a shared lock is placed on the row to be updated when a duplicate-key error occurs. An exclusive index-record lock is taken for a duplicate primary key value. An exclusive next-key lock is taken for a duplicate unique key value.
翻译：INSERT ... ON DUPLICATE KEY UPDATE 与简单插入的不同之处在于，当发生重复键错误时，将在要更新的行上放置排他锁而不是共享锁。对重复的主键值采取独占索引记录锁。对重复的唯一键值使用独占的next-key锁。
REPLACE is done like an INSERT if there is no collision on a unique key. Otherwise, an exclusive next-key lock is placed on the row to be replaced.
翻译：如果唯一键上没有冲突，替换就像插入一样完成。否则，将在要替换的行上放置一个独占的next-key锁。
INSERT INTO T SELECT ... FROM S WHERE ... sets an exclusive index record lock (without a gap lock) on each row inserted into T. If the transaction isolation level is READ COMMITTED, or innodb_locks_unsafe_for_binlog is enabled and the transaction isolation level is not SERIALIZABLE, InnoDB does the search on S as a consistent read (no locks). Otherwise, InnoDB sets shared next-key locks on rows from S. InnoDB has to set locks in the latter case: During roll-forward recovery using a statement-based binary log, every SQL statement must be executed in exactly the same way it was done originally.
翻译：INSERT INTO T SELECT ... FROM S WHERE ... 在T表上已被插入的每一条记录上设置一个排他的索引记录锁(没有间隙锁) .如果事务隔离级别读已提交,或启用innodb_locks_unsafe_for_binlog同时事务隔离级别不是序列化,InnoDB在S上执行一个一致读(无锁)的搜索。否则，InnoDB在S的所有行上设置共享的next-key锁。InnoDB在后面这种情况下必须设置锁：在使用statement-based的二进制日志回滚恢复期间，每条SQL语句都必须按照与最初完全相同的方式执行。
CREATE TABLE ... SELECT ... performs the SELECT with shared next-key locks or as a consistent read, as for INSERT ... SELECT.
When a SELECT is used in the constructs REPLACE INTO t SELECT ... FROM s WHERE ... or UPDATE t ... WHERE col IN (SELECT ... FROM s ...), InnoDB sets shared next-key locks on rows from table s.
翻译：当在使用SELECT构造REPLACE INTO t SELECT ... FROM s WHERE ... or UPDATE t ... WHERE col IN (SELECT ... FROM s ...)时，InnoDB在表s中的行上设置了共享的next-key锁。
参考mysql官方文档链接：
185
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
