看完这篇你就懂Mysql事务隔离级别与锁机制！！！

当几个不同的请求同时对一行数据进行操作，是一定会存在并发的问题。
mysql给我们设计了一些机制来解决这些问题。如事务隔离机制、锁机 制、MVCC多版本并发控制隔离机制，用一整套机制来解决多事务并发问题。

Mysql事务及ACID特性详细解读

事务是由一组SQL语句组成的逻辑处理单元,事务具有以下4个属性,
通常简称为事务的ACID属性。

1.原子性(Atomicity) ：事务是一个原子操作单元,其对数据的修改,要么全都执行
  要么全都不执行。 操作级别

2.一致性(Consistent) ：在事务开始和完成时,数据都必须保持一致状态。
  这意味着所有相关的数据规 则都必须应用于事务的修改,以保持数据的完整性。
  数据级别
  
3.隔离性(Isolation) ：每个事务之间不能相互影响，比如我第一个事务开启查询
  库存是10，第2个事务开启变成了5，那么第一个事务查询还是10。不会因为
  第2个事务影响。

4.持久性(Durable) ：事务完成之后,它对于数据的修改是永久性的,
  即使出现系统故障也能够保持。

并发事务处理带来的问题
更新丢失(Lost Update)或脏写:
看图：

脏读：
事务A读取到了事务B已经修改但尚未提交的数据，看图

不可重复读
事务A内部的相同查询语句在不同时刻读出的结果不一致，不符合隔离性。

幻读
事务A读取到了事务B提交的新增数据，不符合隔离性

Mysql事务隔离级别详解

“脏读”、“不可重复读”和“幻读”,其实都是数据库读一致性问题,
 必须由数据库提供一定的事务隔离机制来解决

一会通过实战看下这张表，
常看当前数据库的事务隔离级别: show variables like ‘tx_isolation’;
设置事务隔离级别：set tx_isolation=‘REPEATABLE-READ’;
Mysql默认的事务隔离级别是可重复读，用Spring开发程序时，如果不设置隔离级别默认用Mysql设置的隔 离级别，如果Spring设置了就用已经设置的隔离级别

Mysql锁机制详解

锁是计算机协调多个进程或线程并发访问某一资源的机制。
前面的几个并发问题中，我们完全可以加1把锁，将1个事务锁上，在这个事务执行完毕前，其他事务不能进行任务操作。
锁分类

从性能上分为乐观锁(用版本对比来实现)和悲观锁 

从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)
 读锁（共享锁，S锁(Shared)）：针对同一份数据，多个读操作可以同时进行
      而不会互相影响 
 写锁（排它锁，X锁(eXclusive)）：当前写操作没有完成前，它会阻断其他写锁
      和读锁 
 从对数据操作的粒度分，分为表锁和行锁

案例演示隔离级别

准备数据表

1.读未提交

万一有脏读，用这种语句去更新：update account set balance = balance - 50 where id =1。
用这种数据库实时数据。

  2.读已提交

3.可重复读

在客户端A，接着执行update account set balance = balance - 50 where id = 1，balance没有变成 400-50=350，lilei的balance值用的是步骤2中的350来算的，所以是300，数据的一致性倒是没有被破坏。可 重复读的隔离级别下使用了MVCC(multi-version concurrency control)机制，select操作不会更新版本号， 是快照读（历史版本）；insert、update和delete会更新版本号，是当前读（当前版本）。

可串行化

在可重复读下及之前的隔离级别，select语句是不会加锁的。在可串行化下读语句都会加锁。串行化就用到了锁机制。

串行化很少用，效率非常低。

如果只查1条记录，则只会对一条记录加锁

当然查全表是不能查的了，唯独id为6的查不了，因为客户端B插入成功了id位6的。这样就解决幻读了。
但是这种串行化效率太低，连select这样的操作都会加锁，所以很少使用。串行化没有任何并发问题。

为什么采取可重复读呢，就是让它在读的时候不加锁。

间隙锁

就是锁住俩个数据之间的空隙。

对这些空的间隙加锁就是间隙锁，可重复读可以通过间隙锁在某种情况可以解决幻读。

在Session_1下面执行 update account set name = ‘zhuge’ where id > 8 and id <18;，则其他Session没 有在这个范围所包含的所有行记录以及行记录所在的间隙里插入或修改任何数据，即id在(3,20]区间都无法修 改数据，注意最后那个20也是包含在内的。 间隙锁是在可重复读隔离级别下才会生效。

行记录所在的间隙里就是下面这个例子。
一共有3个间隙3-10，10-20，20-正无穷。落到这个间隙范围里的所有值都会加锁，所以上边的客户端A更新id 8-18的记录，那么客户端B，是不能插入id为19的。19在10-20里。那么插入是不成功的。
再比如，update account set name = ‘zhuge’ where id > 8 and id <25，那么插入100是不成功的，25在20-正无穷的间隙里，所以插入100是插入不了的，100在20到正无穷的区间里。

这地方有点绕不好理解的话，自己去执行以下，再结合文字就理解了

无索引行锁会升级为表锁

锁主要是加在索引上，如果对非索引字段更新，行锁可能会变表锁
如下例，

索引是非常重要的。

锁定某一行还可以用lock in share mode(共享锁) 和for update(排它锁)，例如：select * from test_innodb_lock where a = 2 for update; 这样其他session只能读这行数据，修改则会被阻塞，直到锁定 行的session提交

行锁分析、死锁

对各个状态量的说明如下： 标粗的是比较重要的
Innodb_row_lock_current_waits: 当前正在等待锁定的数量
Innodb_row_lock_time: 从系统启动到现在锁定总时间长度
Innodb_row_lock_time_avg: 每次等待所花平均时间
Innodb_row_lock_time_max：从系统启动到现在等待最长的一次所花时间
Innodb_row_lock_waits:系统启动后到现在总共等待的次数

     尤其是当等待次数很高，而且每次等待时长也不小的时候，
     我们就需要分析系统中为什么会有如此多的等待， 
     然后根据分析结果着手制定优化计划。

死锁
set tx_isolation=‘repeatable-read’;
Session_1执行：select * from account where id=1 for update;
Session_2执行：select * from account where id=2 for update;
Session_1执行：select * from account where id=2 for update;
Session_2执行：select * from account where id=1 for update;

查看近期死锁日志信息：show engine innodb status\G;
大多数情况mysql可以自动检测死锁并回滚产生死锁的那个事务，

但是有些情况mysql没法自动检测死锁

锁优化建议

1. 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁
2. 合理设计索引，尽量缩小锁的范围
3. 尽可能减少检索条件范围，避免间隙锁
4. 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行
5. 尽可能低级别事务隔离

对于第二条

对于第四条比如，减库存操作和其他操作没有什么关联的时候，可以放到最后执行。