面试官问我知不知道 MySQL 的锁，接下来的 10 分钟让他刮目相看

锁的概念

锁机制是用于管理对共享资源的并发访问。InnoDB存储引擎会在行级别上对数据上锁。数据库使用锁是为了支持对共享资源进行并发访问，提供数据的完整性和一致性。

lock 与 latch

latch 一般称为闩锁（轻量级的锁），因为其要求锁定的时间必须要非常短。在innoDB存储引擎中，latch可以分为mutex(互斥量)和rwlock（读写锁），目的是用来保证并发线程操作临界资源的正确性。

lock的对象是事务，用来锁定的是数据库的对象，例如表、页、行。并且一般lock的对象仅在事务commit或rollback后进行释放。lock是有死锁机制。

锁的类型

Mysql可以分为表锁，行锁，页锁，不同存储引擎锁的特性不一样。

行锁

行锁就是在数据行上加锁，开销大，加锁慢，可能会出现死锁，锁的粒度小，发生锁冲突概率低，并发度高。

在innoDB存储引擎中实现了两种类型的行锁：

• 共享锁（s）：又称读锁。允许一个事务去读一行。若事务T对数据对象A加上S锁， 则事务T可以读A但不能修改A，其他事务只能对A加S锁，不能加X锁。

• 排他锁（X）: 又称写锁，允许获取排它锁的事务更新数据，阻止其他事务去的相同数据共享读锁和排他写锁。

页锁

页锁就是在每一页进行加锁，开销在行锁和表锁之间，会出现死锁，锁定粒度介于表锁和行锁之间，并发度一般。

表锁

表锁就是在表级别加锁，加锁快，开销小，不会出现死锁；锁粒度大，所以发生锁冲突概率高，并发度最低。

意向锁

为允许行锁和表锁共享，实现多粒度锁机制，InnoDB引入了意向锁，意向锁是InnoDB自动加的，不需要用户干预，也就有了意向共享锁和意向排他锁，这两种意向锁都是InnoDB内部使用的，属于表锁。

如果不加意向锁会出现什么问题？

假如事务A对某一行进行加写锁，事务B对整个表加写锁，对整个表加写锁是什么概念就是可以任意修改表中任意一行，但是事务A已经持有某一行的写锁，这和行锁就发送了冲突，为了避免这种冲突，就有了意向锁，事务A对某行加锁之前会对表加个意向排他锁，这样如果事务B要对整行加锁就加不了，因为这个表中有意向排他锁，只能等事务A释放锁才能加。

如果某些资源想要给某一行添加一个排他锁或者共享锁，那么就必须先对表加上意向共享锁或者意向排他锁，只有添加成功，才能进一步对想要的行进行加锁，没添加成功说明有事务对整张表加了锁。

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

• 意向排他锁（IX）: 事务打算给数据行加排他锁，事务在给一个数据行加排他锁前必须先取得该表的IS锁。

间隙锁

是Innodb在可重复读提交下为了解决幻读问题时引入的锁机制,这里举个例子，例如排队，a,b,c，这时候D也来排队，但不能让d排在b旁边，怎么做才能不让d排在b旁边呢，那就是再ab之间，bc之间加锁，让其无法插入进去，而这个锁就相当于间隙锁。

当我们用范围条件而不是相等条件检索数据，并请求共享或者排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁，对于键值在条件范围内但并不存在的记录，叫做间隙，InnoDB也会对这个间隙加锁，这种锁机制就是所谓的间隙锁，除了通过范围条件加锁时可能会使用到间隙锁，如果使用相等条件请求给一个不存在的记录加锁，InnoDB也会使用间隙锁，这样就不会发生幻读的产生。

死锁

死锁是指两个或两个以上的事务在执行过程

死锁可能发生在不同的事务都会对多个相同的表和相同的行上施加锁，但是对表的操作顺序不相同。

解决死锁的方式

• 超时机制，在当两个事务相互等待，当一个等待时间超过了设置的某一阀值时，其中一个事务进行回滚，另一个等待事务就能继续进行。在InnoDB存储引擎中，参数innodb_lock_wait_timeout用来设置超时的时间。

• wait-for graph的方式来进行死锁检测。这是一种较为主动的死锁检测机制，在每个事务请求所并发生等待时都会判断是否存在回路，若存在则有死锁，通常innoDB存储引擎选择回滚undo量最小的事务。

悲观锁

在关系数据库管理系统里，悲观并发控制（又名“悲观锁”，Pessimistic Concurrency Control，缩写“PCC”）是一种并发控制的方法。它可以阻止一个事务以影响其他用户的方式来修改数据。如果一个事务执行的操作都某行数据应用了锁，那只有当这个事务把锁释放，其他事务才能够执行与该锁冲突的操作。悲观并发控制主要用于数据争用激烈的环境，以及发生并发冲突时使用锁保护数据的成本要低于回滚事务的成本的环境中。

就是对数据的冲突采取一种悲观的态度，也就是说假设数据肯定会冲突，所以在数据开始读取的时候就把数据锁定住。

悲观锁执行流程

在对任意记录进行修改前，先尝试为该记录加上排他锁（exclusive locking）。如果加锁失败，说明该记录正在被修改，那么当前查询可能要等待或者抛出异常。 具体响应方式由开发者根据实际需要决定。如果成功加锁，那么就可以对记录做修改，事务完成后就会解锁了。其间如果有其他对该记录做修改或加排他锁的操作，都会等待我们解锁或直接抛出异常。

乐观锁

在关系数据库管理系统里，乐观并发控制（又名“乐观锁”，Optimistic Concurrency Control，缩写“OCC”）是一种并发控制的方法。它假设多用户并发的事务在处理时不会彼此互相影响，各事务能够在不产生锁的情况下处理各自影响的那部分数据。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。如果其他事务有更新的话，正在提交的事务会进行回滚。

乐观锁（ Optimistic Locking ） 相对悲观锁而言，乐观锁假设认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回用户错误的信息，让用户决定如何去做。相对于悲观锁，在对数据库进行处理的时候，乐观锁并不会使用数据库提供的锁机制。一般的实现乐观锁的方式就是记录数据版本。

乐观锁实现流程

实现：大多数基于数据版本（Version）记录机制实现

具体可通过给表加一个版本号或时间戳字段实现，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值加一。当我们提交更新的时候，判断当前版本信息与第一次取出来的版本值大小，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，拒绝更新，让用户重新操作。