MySQL——InnoDB锁问题（三）

一、InnoDB行锁模式和加锁方法。

InnoDB表实现了以下两种形式的行锁。

（1）共享锁（S）：允许一个事务去读一行，阻止其他事务获得相同数据集的排他锁。

（2）排他锁（X）：允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享读锁和排他写锁。

另外，为了允许行锁和表锁的共存，实现多粒度锁机制，InnoDB还有两种内部使用的意向锁，这两种意向锁都是表锁。

（a）、意向共享锁（IS）：事务打算给数据行加行共享锁，事务在给一个数据行加共享锁前，必须先取得该表的意向共享锁（IS）。

（b）、意向排它锁（IX）：事务打算给数据行加行排它锁，事务在给一个数据行加排它锁前，必须先取得该表的意向排它锁（IX）。

以下为这四种锁之间的兼容情况：

如果一个事务请求的锁模式和当前的锁兼容，InnoDB就将锁给予该事务；反之，如果两者不兼容，该事务必须等待锁释放。意向锁是InnoDB自己加的，不需用户干预。对于update，delete，insert语句，InnoDB会自己给涉及的语句添加排他锁（X）；对于普通的select语句，innodb不会添加任何锁。

事务可以通过一下语句显示给记录集添加共享锁或排他锁。

（a）共享锁（S）：SELECT * FROM  table_name  WHERE  ....  LOCK   IN  SHARE MODE.

（b）排他锁（X）：SELECT * FROM  table_name  WHERE  ....  FOR UPDATE.

使用SELECT  ....  IN SHARE MODE 获得共享锁，主要用在需要数据依存关系时来确认某行记录是否存在，并确保没人对这行记录进行UPDATE 或者 DELETE 操作。但是如果当前事务也需要对该记录进行更新操作，则很有可能造成死锁。对于锁定行记录后，当前事务需要对该记录进行更新操作的情况，应该使用SELECT  ....  FOR UPDATE 方式，获取排它锁。

如下例子是使用SELECT ....  IN SHARE MODE 获得排他锁后需要更新记录的，看看会怎么样。其中actor表的actor_id为主键。

   当时使用SELECT .... FOR UPDATE 获取排它锁后，再更新记录：