Mysql共享锁、排他锁、悲观锁、乐观锁

1、相关名词

　　|--表级锁（锁定整个表）

　　|--页级锁（锁定一页）

　　|--行级锁（锁定一行）

　　|--共享锁（S锁，MyISAM 叫作读锁）

　　|--排他锁（X锁，MyISAM 叫作写锁）

　　|--间隙锁（NEXT-KEY锁）

　　|--悲观锁（抽象性，不真实存在这个锁）

　　|--乐观锁（抽象性，不真实存在这个锁）

 

2、InnoDB与MyISAM

　　Mysql 在5.5以前默认使用 MyISAM 存储引擎，以后使用 InnoDB 。查看当前存储引擎：

show variables like '%storage_engine%';

　　MyISAM 操做数据都是使用的表锁，你更新一条记录就要锁整个表，致使性能较低，并发不高。固然同时它也不会存在死锁问题。

　　而 InnoDB 与 MyISAM 的最大不一样有两点：一是 InnoDB 支持事务；二是 InnoDB 采用了行级锁。也就是你须要修改哪行，就能够只锁定哪行。

　　在 Mysql 中，行级锁并非直接锁记录，而是锁索引。索引分为主键索引和非主键索引两种，若是一条sql 语句操做了主键索引，Mysql 就会锁定这条主键索引；若是一条语句操做了非主键索引，MySQL会先锁定该非主键索引，再锁定相关的主键索引。

　　InnoDB 行锁是经过给索引项加锁实现的，若是没有索引，InnoDB 会经过隐藏的聚簇索引来对记录加锁。也就是说：若是不经过索引条件检索数据，那么InnoDB将对表中全部数据加锁，实际效果跟表锁同样。由于没有了索引，找到某一条记录就得扫描全表，要扫描全表，就得锁定表。

 

3、共享锁与排他锁

　1.首先说明：数据库的增删改操做默认都会加排他锁，而查询不会加任何锁。

　　mysql InnoDB引擎默认的修改数据语句，update,delete,insert都会自动给涉及到的数据加上排他锁，select语句默认不会加任何锁类型，若是加排他锁可使用select ...for update语句，加共享锁可使用select ... lock in share mode语句。因此加过排他锁的数据行在其余事务种是不能修改数据的，也不能经过for update和lock in share mode锁的方式查询数据，但能够直接经过select ...from...查询数据，由于普通查询没有任何锁机制。

　　|--共享锁：对某一资源加共享锁，自身能够读该资源，其余人也能够读该资源（也能够再继续加共享锁，即 共享锁可多个共存），但没法修改。要想修改就必须等全部共享锁都释放完以后。语法为：

select * from table lock in share mode

　　|--排他锁：对某一资源加排他锁，自身能够进行增删改查，其余人没法进行任何操做。语法为：

select * from table for update

　2.下面援引例子说明 （援自：http://blog.csdn.net/samjustin1/article/details/52210125）：

　　这里用T1表明一个数据库执行请求，T2表明另外一个请求，也能够理解为T1为一个线程，T2 为另外一个线程。

例1：------------------------------------------------------------------------------------------

　　T1:  select * from table lock in share mode（假设查询会花很长时间，下面的例子也都这么假设）

　　T2:  update table set column1='hello'

　　过程：

　　　　T1运行（并加共享锁)

　　　　T2运行

　　　　if T1还没执行完

　　　　T2等......

　　　　else 锁被释放

　　　　T2执行

　　　　end if

 

　　T2 之因此要等，是由于 T2 在执行 update 前，试图对 table 表加一个排他锁，而数据库规定同一资源上不能同时共存共享锁和排他锁。因此 T2 必须等 T1 执行完，释放了共享锁，才能加上排他锁，而后才能开始执行 update 语句。

例2：------------------------------------------------------------------------------------------

　　T1:  select * from table lock in share mode

　　T2:  select * from table lock in share mode

　这里T2不用等待T1执行完，而是能够立刻执行。

分析：

　　T1运行，则 table 被加锁，好比叫lockA，T2运行，再对 table 加一个共享锁，好比叫lockB，两个锁是能够同时存在于同一资源上的（好比同一个表上）。这被称为共享锁与共享锁兼容。这意味着共享锁不阻止其它人同时读资源，但阻止其它人修改资源。

例3：------------------------------------------------------------------------------------------

　　T1:  select * from table lock in share mode

　　T2:  select * from table lock in share mode

　　T3:  update table set column1='hello'

　T2 不用等 T1 运行完就能运行，T3 却要等 T1 和 T2 都运行完才能运行。由于 T3 必须等 T1 和 T2 的共享锁所有释放才能进行加排他锁而后执行 update 操做。

 

例4 （死锁的发生）：------------------------------------------------------------------------------------------

　　T1:begin tran

     　　select * from table lock in share mode

     　　update table set column1='hello'

　　T2:begin tran

     　　select * from table lock in share mode

     　　update table set column1='world'

　　假设 T1 和 T2 同时达到 select，T1 对 table 加共享锁，T2 也对 table 加共享锁，当 T1 的 select 执行完，准备执行 update 时，根据锁机制，T1 的共享锁须要升级到排他锁才能执行接下来的 update。在升级排他锁前，必须等 table 上的其它共享锁（T2）释放，同理，T2 也在等 T1 的共享锁释放。因而死锁产生了。

例5：------------------------------------------------------------------------------------------

　　T1:begin tran

     　　update table set column1='hello' where id=10

　　T2:begin tran

     　　update table set column1='world' where id=20

　这种语句虽然最为常见，不少人以为它有机会产生死锁，但实际上要看状况

　　|--若是id是主键（默认有主键索引），那么T1会一会儿找到该条记录(id=10的记录），而后对该条记录加排他锁，T2，一样，一会儿经过索引定位到记录，而后对id=20的记录加排他锁，这样T1和T2各更新各的，互不影响。T2也不须要等。

　　|--若是id是普通的一列，没有索引。那么当T1对id=10这一行加排他锁后，T2为了找到id=20，须要对全表扫描。但由于T1已经为一条记录加了排他锁，致使T2的全表扫描进行不下去（实际上是由于T1加了排他锁，数据库默认会为该表加意向锁，T2要扫描全表，就得等该意向锁释放，也就是T1执行完成），就致使T2等待。 

　　死锁怎么解决呢？一种办法是，以下：

例6：------------------------------------------------------------------------------------------

　　T1:begin tran

     　　select * from table for update

     　　update table set column1='hello'

　　T2:begin tran

     　　select * from table for update

     　　update table set column1='world'

　　这样，当 T1 的 select 执行时，直接对表加上了排他锁，T2 在执行 select 时，就须要等 T1 事物彻底执行完才能执行。排除了死锁发生。但当第三个 user 过来想执行一个查询语句时，也由于排他锁的存在而不得不等待，第四个、第五个 user 也会所以而等待。在大并发状况下，让你们等待显得性能就太友好了。

　　因此，有些数据库这里引入了更新锁（如Mssql，注意：Mysql不存在更新锁）。

例7：------------------------------------------------------------------------------------------

T1:begin tran

     select * from table [加更新锁操做]

     update table set column1='hello'

T2:begin tran

     select * from table [加更新锁操做]

     update table set column1='world'

 

　　更新锁其实就能够当作排他锁的一种变形，只是它也容许其余人读（而且还容许加共享锁）。但不容许其余操做，除非我释放了更新锁。T1 执行 select，加更新锁。T2 运行，准备加更新锁，但发现已经有一个更新锁在那儿了，只好等。当后来有 user三、user4...须要查询 table 表中的数据时，并不会由于 T1 的 select 在执行就被阻塞，照样能查询，相比起例6，这提升了效率。

 

后面还有意向锁和计划锁：

　　计划锁，和程序员关系不大，就没去了解。
　　意向锁（innodb特有）分意向共享锁和意向排他锁。
　　意向共享锁：表示事务获取行共享锁时，必须先得获取该表的意向共享锁；
　　意向排他锁：表示事务获取行排他锁时，必须先得获取该表的意向排他锁；
　咱们知道，若是要对整个表加锁，需保证该表内目前不存在任何锁。

　　所以，若是须要对整个表加锁，那么就能够根据：检查意向锁是否被占用，来知道表内目前是否存在共享锁或排他锁了。而不须要再一行行地去检查每一行是否被加锁。

 

4、乐观锁与悲观锁

　　首先说明，乐观锁和悲观锁都是针对读（select）来讲的。

　案例：

　　某商品，用户购买后库存数应-1，而某两个或多个用户同时购买，此时三个执行程序均同时读得库存为“n”，以后进行了一些操做，最后将均执行update table set 库存数=n-1，那么，很显然这是错误的。

 

解决：

　使用悲观锁（其实说白了也就是排他锁）

　　|-- 程序A在查询库存数时使用排他锁（select * from table where id=10 for update）

　　|-- 而后进行后续的操做，包括更新库存数，最后提交事务。

　　|-- 程序B在查询库存数时，若是A还未释放排他锁，它将等待……

　　|-- 程序C同B……
　使用乐观锁（靠表设计和代码来实现）

　　|-- 通常是在该商品表添加version版本字段或者timestamp时间戳字段

　　|-- 程序A查询后，执行更新变成了：
   　　 update table set num=num-1 where id=10 and version=23  

　　这样，保证了修改的数据是和它查询出来的数据是一致的（其余执行程序确定未进行修改）。固然，若是更新失败，表示在更新操做以前，有其余执行程序已经更新了该库存数，那么就能够尝试重试来保证更新成功。为了尽量避免更新失败，能够合理调整重试次数（阿里巴巴开发手册规定重试次数不低于三次）。
总结：对于以上，能够看得出来乐观锁和悲观锁的区别：

　　悲观锁实际使用了排他锁来实现（select **** for update）。文章开头说到，innodb加行锁的前提是：必须是经过索引条件来检索数据，不然会切换为表锁。

　　所以，悲观锁在未经过索引条件检索数据时，会锁定整张表。致使其余程序不容许“加锁的查询操做”，影响吞吐。故若是在查询居多的状况下，推荐使用乐观锁。

　　“加锁的查询操做”：加过排他锁的数据行在其余事务中是不能修改的，也不能经过for update或lock in share mode的加锁方式查询，但能够直接经过select ...from...查询数据，由于普通查询没有任何锁机制。
　　乐观锁更新有可能会失败，甚至是更新几回都失败，这是有风险的。因此若是写入居多，对吞吐要求不高，可以使用悲观锁。
　　　也就是一句话：读用乐观锁，写用悲观锁。

 

间隙锁

　1.什么叫间隙锁
　　当咱们用范围条件而不是相等条件检索数据，并请求共享或排他锁时，InnoDB会给符合条件的已有数据记录的索引项加锁；对于键值在条件范围内但不存在的记录，叫作“间隙(GAP)”，InnoDB也会对这个“间隙”加锁，这种锁机制就是所谓的间隙锁(NEXT-KEY)锁。

　2.间隙锁的产生
　　上面的文字很抽象，如今举个栗子，介绍间隙锁是怎么产生的：

假设有如下表t_student：（其中id为PK，name为非惟一索引）

　这个时候咱们发出一条这样的加锁sql语句：

　　select id,name from t_student where id > 0 and id < 5 for update;

　这时候，咱们命中的数据为如下着色部分：

 

　　细心的朋友可能就会发现，这里缺乏了条id为2的记录，咱们的重点就在这里。

　　select ... for update这条语句，是会对数据记录加锁的，这里由于命中了索引，加的是行锁。从数据记录来看，这里排它锁锁住数据是id为一、3和4的这3条数据。

　　可是，看看前面咱们的介绍——对于键值在条件范围内但不存在的记录，叫作“间隙(GAP)”，InnoDB也会对这个“间隙”加锁。

　　好了，咱们这里，键值在条件范围可是不存在的记录，就是id为2的记录，这里会对id为2数据加上间隙锁。假设这时候若是有id=2的记录insert进来了，是要等到这个事务结束之后才会执行的

　3.间隙锁的做用
　　　总的来讲，有2个做用：防止幻读和防止数据误删/改

　　(1)防止幻读
　　　　关于幻读的概念能够参考这篇文章 https://blog.csdn.net/mweibiao/article/details/80805031 ，这里就很少作解释了

　假设有下面场景

　　若是没有间隙锁，事务A在T1和T4读到的结果是不同的，有了间隙锁，读的就是同样的了

　　(2)防止数据误删/改

　　　这个做用比较重要，假设如下场景：

　　这种状况下，若是没有间隙锁，会出现的问题是：id为2的记录，刚加进去，就被删除了，这种状况有时候对业务，是致命性的打击。加了间隙锁以后，因为insert语句要等待事务A执行完以后释放锁，避免了这种状况

　4.使用间隙锁的隐患
　最大的隐患就是性能问题

　　前面提到，假设这时候若是有id=2的记录insert进来了，是要等到这个事务结束之后才会执行的，假设是这种场景

　　这种状况，对插入的性能就有很大影响了，必须等到事务结束才能进行插入，性能大打折扣

　　更有甚者，若是间隙锁出现死锁的状况下，会更隐晦，更难定位

 

怎样避免死锁 　　

　　一、以固定的顺序访问表和行。好比两个更新数据的事务，事务A 更新数据的顺序 为1，2；事务B更新数据的顺序为2，1。这样更可能会形成死锁。

　　二、大事务拆小。大事务更倾向于死锁，若是业务容许，将大事务拆小。

　　三、在同一个事务中，尽量作到一次锁定所须要的全部资源，减小死锁几率。

　　四、下降隔离级别。若是业务容许，将隔离级别调低也是较好的选择，好比将隔离级别从RR调整为RC，能够避免掉不少由于gap锁形成的死锁。

　　五、为表添加合理的索引。能够看到若是不走索引将会为表的每一行记录添加上锁，死锁的几率大大增大。

 

 资料出处：

　　　　　　https://blog.csdn.net/mweibiao/article/details/81672315?utm_source=blogxgwz8

　　　　　　https://blog.csdn.net/localhost01/article/details/78720727