当Mysql - InnoDB行锁遇到复合主键和多列索引

背景

今天在配合其他项目组做系统压测，过程中出现了偶发的死锁问题。分析代码后发现有复合主键的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/DELETE操作会产生行锁，也可以显示的添加行锁（也就是平时所说的“悲观锁”）

select for update
lock in share mode

锁算法

Inn