Mysql的锁机制（一）

总的来说，Mysql各存储引擎使用了三种类型的锁定机制：行锁定，页级锁定和表级锁定。下面我们简要进行分析这三种锁定的特点和各自的优劣。

1.行级别锁定

特点：
开销大，加锁慢；会出现死锁；锁定粒度最小，发生锁冲突的概率最低，并发度也最高。
InnoDB实现了两种类型的行级锁——共享锁和排他锁。在锁定机制的实现过程中为了让行级锁定和表级锁定共存，InnoDB使用了两种内部使用的意向锁，也就是意向共享锁和意向排他锁。

共享锁（S）
允许一个事务读一行数据时阻止其他的事务读取相同数据的排他锁。( Select * from table_name where …lock in share mode)。

排他锁（X）
允许获得排他锁的事务更新数据，阻止其他事务取得相同数据集的共享锁和排他锁。(select * from table_name where…for update) 。

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

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

2.表级锁定

特点：
开销小，加锁快；不会出现死锁；锁定粒度大，发出锁冲突的概率最高，并发度最低。
MySQL数据库的表级锁定主要分为两种类型：读锁定和写锁定。
提供了四种队列来维护这两种锁。

• Current read lock queue (lock -> read)
• Padding read lock queue (lock -> read wait)
• Current write lock queue (lock -> write)
• Padding read lock queue (lock -> write wait)

当前持有读锁的所有线程相关信息都能够在Current read-lock queue中找到，队列中的信息按照获取到锁的时间顺序依序存放。而正在等待锁定资源的信息则存放在Pending read-lock queue里，另外两个存放写锁信息的队列也按照上面相同规则来存放信息。

3.页级锁

页级锁是MySQL中锁定粒度介于行级锁和表级锁中间的一种锁。表级锁速度快，但冲突多，行级冲突少，但速度慢。所以取了折衷的页级，一次锁定相邻的一组记录。

特点:
开销和加锁时间界于表锁和行锁之间；会出现死锁；锁定粒度界于表锁和行锁之间，并发度一般。

乐观锁与悲观锁

乐观并发控制和悲观并发控制是并发控制采用的主要方法。乐观锁和悲观锁不仅在关系数据库里应用，在Hibernate、Memcache等等也有相关概念。

悲观锁

现在互联网高并发的架构中，受到fail-fast思路的影响，悲观锁已经非常少见了。

悲观锁(Pessimistic Locking)，悲观锁是指在数据处理过程，使数据处于锁定状态，一般使用数据库的锁机制实现。

在MySQL中使用悲观锁，必须关闭MySQL的自动提交，set autocommit=0，MySQL默认使用自动提交autocommit模式，也即你执行一个更新操作，MySQL会自动将结果提交。

set autocommit=0

假设商品表中有一个字段quantity表示当前该商品的库存量。假设有一件商品，其id为100，quantity=8个；如果不使用锁，那么操作方法

//step1: 查出商品剩余量
 select quantity from items where id=100;
//step2: 如果剩余量大于0，则根据商品信息生成订单
 insert into orders(id,item_id) values(null,100);
 //step3: 修改商品的库存
 update Items set quantity=quantity-1 where id=100;

这样子的写法在高并发环境下可能出现问题。
假设两位销售在售楼部得知只有一套房（step1），但是跑到大街上找到了两位不同的客户签了卖房合同（step2），这个时候仍然去执行step3，就造成了超卖。

但是使用悲观锁，就可以解决这个问题，在上面的场景中，商品信息从查询出来到修改，中间有一个生成订单的过程，使用悲观锁的原理就是，当我们在查询出items信息后就把当前的数据锁定，直到我们修改完毕后再解锁。那么在这个过程中，因为数据被锁定了，就不会出现有第三者来对其进行修改了。而这样做的前提是需要将要执行的SQL语句放在同一个事物中，否则达不到锁定数据行的目的。

//step1: 查出商品状态
select quantity from items where id=100 for update;
//step2: 根据商品信息生成订单
insert into orders(id,item_id) values(null,100);
//step3: 修改商品的库存
update Items set quantity=quantity-2 where id=100;

注意：在MySQL中用悲观锁务必须确定走了索引，而不是全表扫描，否则将会将整个数据表锁住。

悲观锁并不是适用于任何场景，它也存在一些不足，因为悲观锁大多数情况下依靠数据库的锁机制实现，以保证操作最大程度的独占性。如果加锁的时间过长，其他用户长时间无法访问，影响了程序的并发访问性，同时这样对数据库性能开销影响也很大，特别是对长事务而言，这样的开销往往无法承受，这时就需要乐观锁。

乐观锁

乐观锁相对悲观锁而言，它认为数据一般情况下不会造成冲突，所以在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果发现冲突了，则让返回错误信息，让用户决定如何去做。接下来我们看一下乐观锁在数据表和缓存中的实现。

实现数据版本有两种方式，第一种是使用版本号，第二种是使用时间戳。

利用数据版本号（version）机制是乐观锁最常用的一种实现方式。一般通过为数据库表增加一个数字类型的 “version” 字段，当读取数据时，将version字段的值一同读出，数据每更新一次，对此version值+1。当我们提交更新的时候，判断数据库表对应记录的当前版本信息与第一次取出来的version值进行比对，如果数据库表当前版本号与第一次取出来的version值相等，则予以更新，否则认为是过期数据，返回更新失败。

//step1: 查询出商品信息
select (quantity,version) from items where id=100;
//step2: 根据商品信息生成订单
insert into orders(id,item_id) values(null,100);
//step3: 修改商品的库存
update items set quantity=quantity-1,version=version+1 where id=100 and version=#{version};

优点与不足
乐观并发控制相信事务之间的数据竞争(data race)的概率是比较小的，因此尽可能直接做下去，直到提交的时候才去锁定，所以不会产生任何锁和死锁。但如果直接简单这么做，还是有可能会遇到不可预期的结果，例如两个事务都读取了数据库的某一行，经过修改以后写回数据库，这时就遇到了问题。