当Mysql行锁遇到复合主键与多列索引详解

背景

今天在配合其他项目组做系统压测，过程中出现了偶发的死锁问题。分析代码后发现有复合主键的update情况，更新复合主键表时只使用了一个字段更新，同时在事务内又有对该表的insert操作，结果出现了偶发的死锁问题。

比如表t_lock_test中有两个主键都为primary key(a,b) ，但是更新时却通过update t_lock_test .. where a = ? ，然后该事务内又有insert into t_lock_test values(...)

InnoDB中的锁算法是Next-Key Locking，很可能是因为这个点导致的死锁，但是复合主键下会出发Next-Key Locking吗，那多列联合unique索引下又会触发Next-Key Locking吗，书上并没有找到答案，得实际测试一下。

InnoDB中的锁

锁是数据库系统区别于文件系统的一个关键特性。锁机制用于管理对共享资源的并发访[插图]。InnoDB存储引擎会在行级别上对表数据上锁，这固然不错。不过InnoDB存储引擎也会在数据库内部其他多个地方使用锁，从而允许对多种不同资源提供并发访问。例如，操作缓冲池中的LRU列表，删除、添加、移动LRU列表中的元素，为了保证一致性，必须有锁的介入。数据库系统使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。

由于使用锁时基本都是在InnoDB存储引擎下，所以跳过MyISAM，直接讨论InnoDB。

锁类型

InnoDB存储引擎实现了如下两种标准的行级锁：

• 共享锁(S Lock)，允许事务读一行数据
• 排它锁(x lOCK)，允许事务删除或更新一条数据

如果一个事务T1已经获得了r的共享锁，那么另外的事务T2可以立即获得行r的共享锁，因为读取并没有改变r的数据，成这种情况为锁兼容（Lock Compatible）。但若有其他的事务T3箱获得行r的排它锁，则比如等待T1、T2释放行r上的共享锁——这种情况称为锁不兼容。

排它锁和共享锁的兼容性：

InnoDB中对数据进行Update操作会产生行锁，也可以显示的添加行锁（也就是平时所说的“悲观锁”）

select for update

锁算法

InnoDB有3种行锁的算法，其分别是：

Record Lock：单个行记录上的锁，就是字面意思的行锁

Record Lock会锁住索引记录(注意这里说的是索引，因为InnoDB下主键索引即数据),ruguo InnoDB存储引擎表在建立的时候没有设置任何一个索引，那么这时对InnoDB存储引擎会使用隐士的主键来进行锁定。

Gap Lock：间隙锁，锁定一个范围，但不包含记录本身

Next-Key Lock：Gap Lock+Record Lock，锁定一个范围，并且锁定记录本身

Gap Lock和Next-Key Lock的锁定区间划分原则是一样的。

例如一个索引有本文来源gao*daima.com搞@代#码&网610/11/13和20这四个值，那么该索引被划分的的区间为：

(-∞,10]
(10,11]
(11,13]
(13,20]
(20,+∞]

采用Next-Key Lock的锁定技术称为Next-Key Locking。其设计的目的是为了解决Phantom Problem，这将在下一小节中介绍。而利用这种锁定技术，锁定的不是单个值，而是一个范围，是谓词锁（predict lock）的一种改进。

喜欢 (0)赏

[搞代码]

分享 (0)