14.5.3 Locks Set by Different SQL Statements in InnoDB 通过不同的SQL语句设置的锁 在InnoDB中 一个锁定读, 一个UPDATE 或者一个DELETE 通常设置record locks 在每个Index record 他不管是否有WHERE 条件在与距离 会排除记录。 InnoDB 不记住准确的WHERE 条件, 只是知道哪个index range 是被扫描。 locks通常是 next-key locks 也堵塞inserts 到"gap" 在那个记录前。 然而,区间锁可以显示的关闭,这将导致 next-key locking不能被使用 如果一个secondary index 是用于一个搜索,index record locks 会被设置为排他。 InnoDB 也会检索相应的clustered index records 在它们上面设置锁 如果你没有合适的索引用于你的语句,MySQL 必须扫描整个表来处理语句,表的每行记录都会被锁定， 从而阻止其他用于所有的插入到这个表。 创建好的索引是重要的,这样你的查询不会扫描很多的记录 对于SELECT ... FOR UPDATE or SELECT ... LOCK IN SHARE MODE, 锁是需要的对于扫描的记录 期望被释放对于记录不符合纳入结果集的( 比如,如果你不满足给定的WHERE 条件的标准). 然而, 在一些例子中,记录可能不会被立即锁定 因为一个结果集和他的原始资料的关系是丢失了再查询执行时。 比如,在一个UNION 扫描的(被锁定的)的记录从一个表可能会被插入到一个临时表 InnoDB 设置锁的特定类型: 1.SELECT ... FROM 是一个一致性读, 从数据库读取快照 没有设置锁除非事务隔离是设置为SERIALIZABLE 对于SERIALIZABLE level,搜索设置共享的next-key locks 在index records. 然而,只有Index record lock 是需要的 用于语句 锁定记录使用一个unique index 来搜索唯一行 2.SELECT ... FROM ... LOCK IN SHARE MODE 设置共享next-key locks 在所有的搜索遇到的index 记录。 然而, 只有一个index record lock 是需要的用于语句 锁定记录使用一个unique index 来搜索唯一的记录 3.SELECT ... FROM ... FOR UPDATE 设置一个排他的 next-key lock 在每条搜索遇到的记录。 然而, 只有一个Index record lock 是需要的用于语句 locks rows 使用一个唯一索引来搜搜唯一的记录 4.对于搜搜遇到的index records, SELECT ... FROM ... FOR UPDATE 堵塞其他会话 执行SELECT ... FROM ... LOCK IN SHARE MODE 或者 在某些事物蛤蜊级别。 一致性读 会忽略任何锁定 5.UPDATE ... WHERE ... 设置一个排他的e next-key lock 在每个记录。 然而, 只有一个Index record 锁是需要的用于语句当locks row 是使用一个唯一索引来进行唯一搜索 6.当UPDATE 协议一个clustered index record, 隐式的锁是被设置影响secondary index records. UPDATE 操作也会设置shared locks 在影响的secondary index records 当执行重复的检查扫描 7.DELETE FROM ... WHERE ... 设置一个排他的 next-key lock 在每个搜索遇到的记录 然而,只有一个index record lock 是需要的用于语句 lock rows 使用一个唯一索引来搜索一个唯一的记录 8.在插入行之前,一种区间锁类型被称为insert intention gap lock 被设置。 lock 表明意向插入以这种方式多个事务插入到相同的index gap 不需要相互等待 如果他们不是插入相同的位置。 假设有index record 值为4和7,单独的事务尝试插入值5和6 每个lock 区间在4和7 使用插入意向锁来得到排他锁在插入的记录, 但是不会相互堵塞 因为记录是不冲突的 如果一个重复的key错误发生,一个共享锁在重复的index上被设置。 这个共享的锁可以导致死锁 有多个会话尝试插入相同的记录 如果另外的会话已经有一个排他锁。 这个可以发生如果另外的会话删除记录 ,假设一个InnoDB 表t1 有下面的结构: CREATE TABLE t1 (i INT, PRIMARY KEY (i)) ENGINE = InnoDB; 现在假设有3个会话执行下面操作按顺序: Session 1: START TRANSACTION; INSERT INTO t1 VALUES(1); Session 2： START TRANSACTION; INSERT INTO t1 VALUES(1); --hang Session 3: START TRANSACTION; INSERT INTO t1 VALUES(1); Session 1: ROLLBACK; Session 1的第一个操作 需要的排他锁用于记录, session 2和session 3 都导致一个重复键错误 他们都请求一个共享锁用于记录。 当session 1回滚, 它释放他的排他锁在记录上 共享锁请求对于session 2和3 是被授予。 在这个时间点,sessions 2 and 3 deadlock: 两者都不能获得一个排他锁用于记录 因为共享锁被其他持有 类似的情况发生 如果表已经包含一个只为1 ,然后3个会话执行相同的操作: mysql> select * from t1; +---+ | i | +---+ | 1 | +---+ 1 row in set (0.00 sec) 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; 首先session 1 操作需要一个排他锁用于记录。 session 2 和session 3 操作都导致一个重复键错误 他们都请求记录的排他锁。 当session 1提交, 他释放他的排他锁在记录上 session 2和session 3请求的共享锁被授权。 在这个时间点,session 2和session 3死锁 两者都不能获得一个排他锁对于记录 因为共享锁被另外一个人持有 1.?INSERT ... ON DUPLICATE KEY UPDATE 不同一个简单的插入 一个排他next-key lock 而不是一个共享锁 2.REPLACE 是像一个INSERT 如果没有冲突在一个唯一键。 否则,一个排他的next-key lock是放置在replaces 的记录上 3.INSERT INTO T SELECT ... FROM S WHERE ... 设置一个排他锁 record lock(没有间隙锁) 在每个插入的记录。 如果事务隔离级别是READ COMMITTED,或者 innodb_locks_unsafe_for_binlog 是被启用的 且事务隔离级别不是SERIALIZABLE, CREATE TABLE ... SELECT ... 执行SELECT YOU shared next-key locks 或者作为一个一致性读,和 INSERT ... SELECT. 当初始化一个先前指定的 AUTO_INCREMENT 列在一个表上, InnoDB 设置一个排他锁在 索引相关自增列的尾部。