Mysql中的锁&数据库事务

锁是计算机协调多个进程或线程并发访问某一资源的机制。
在数据库中，除传统的计算资源（如CPU、RAM、I/O等）的争用以外，数据也是一种供许多用户共享的资源。如何保证数据并发访问的一致性、有效性是所有数据库必须解决的一个问题，锁冲突也是影响数据库并发访问性能的一个重要因素。从这个角度来说，锁对数据库而言显得尤其重要，也更加复杂。

打个比方，我们到淘宝上买一件商品，商品只有一件库存，这个时候如果还有另一个人买，那么如何解决是你买到还是另一个人买到的问题?这里肯定要用到事务，我们先从库存表中取出物品数量，然后插入订单，付款后插入付款表信息，然后更新商品数量。在这个过程中，使用锁可以对有限的资源进行保护，解决隔离和并发的矛盾。

锁的分类：

从对数据操作的类型（读/写）分： 

1. 读锁(共享锁):针对同一份数据，多个读操作可以同时进行而不会互相影响。
2. 写锁(排它锁）:当前写操作没有完成前，它会阻断其他写锁和读锁。

从对数据操作的粒度：

1. 表锁（偏读）：偏向MyISAM存储引擎，开销小，加锁快;无死锁;锁定粒度大，发生锁冲突的概率最高,并发度最低
2. 行锁：偏向InnoDB存储引擎，开销大，加锁慢﹔会出现死锁;锁定粒度最小，发生锁冲突的概率最低,并发度也最高。

InnoDB 行锁是通过给索引上的索引项加锁来实现的，这一点 MySQL 与Oracle 不同，后者是通过在数据块中对相应数据行加锁来实现的。InnoDB 这种行锁实现特点意味着：只有通过索引条件检索数据，InnoDB 才使用行级锁，否则，InnoDB 将使用表锁！

在介绍锁之前先了解一下数据库事务的几个点，数据库事务有不同的隔离级别，不同的隔离级别对锁的使用是不同的，锁的应用最终导致不同事务的隔离级别。 

Mysql数据库事务

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

1. 原子性(Atomicity)：事务是一个原子操作单元，其对数据的修改，要么全都执行，要么全都不执行。
2. 一致性(Consistent)：在事务开始和完成时，数据都必须保持一致状态。这意味着所有相关的数据规则都必须应用于事务的修改，以保持数据的完整性;事务结束时，所有的内部数据结构（如B树索引或双向链表）也都必须是正确的。
3. 隔离性(Isolation)：数据库系统提供一定的隔离机制，保证事务在不受外部并发操作影响的“独立”环境执行。这意味着事务处理过程中的中间状态对外部是不可见的，反之亦然。
4. 持久性(Durable)：事务完成之后，它对于数据的修改是永久性的，即使出现系统故障也能够保持。

并发性事务可能带来的问题：

1. 更新丢失：当两个或多个事务选择同一行，然后基于最初选定的值更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题――最后的更新覆盖了由其他事务所做的更新。  例如: 两个程序员修改同一java文件。每个程序员独立更改其副本，然后保存更改后的副本，这样就覆盖了原始文档。最后保存其更改副本的编辑人员覆盖前一个程序员所做的更改。如果在一个程序员完成并提交事务之前，另一个程序员不能访问同一文件，则可避免此问题。
2. 脏读：事务A读取到了事务B已修改但尚未提交的的数据，还在这个数据基础上做了操作。此时，如果B事务回滚，A读取的数据无效，不符合一致性要求。
3. 不可重复读：一个事务在读取某些数据后的某个时间，再次读取以前读过的数据，却发现其读出的数据已经发生了改变、或某些记录已经被删除了!  这种现象就叫做“不可重复读”。一句话:事务A读取到了事务B已经提交的修改数据，不符合隔离性。
4. 幻读：一个事务按相同的查询条件重新读取以前检索过的数据，却发现其他事务播入了满足其查询条件的新数据，这种现象就称为”幻读“。 一句话:事务A读取到了事务B体提交的新增数据，不符合隔离性。幻读和脏读有点类似，脏读是事务B里面修改了数据，幻读是事务B里面新增了数据。

"脏读"、"不可重复读"和"幻读"，其实都是数据库读一致性问题，必须由数据库提供一定的事务隔离机制来解决。数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上“串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏感，可能更关心数据并发访问的能力。

数据库的隔离级别：

1. Read Uncommitted（读取未提交内容）：在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。本隔离级别很少用于实际应用，因为它的性能也不比其他级别好多少。读取未提交的数据，也被称之为脏读（Dirty Read）。
2. Read Committed（读取提交内容）： 这是大多数数据库系统的默认隔离级别（但不是 MySQL 默认的）。它满足了隔离的简单定义：一个事务只能看见已经提交事务所做的改变。这种隔离级别也支持所谓的不可重复读（Nonrepeatable Read），因为同一事务的其他实例在该实例处理其间可能会有新的 commit，所以同一 select 可能返回不同结果。
3. Repeatable Read（可重读）：这是 MySQL 的默认事务隔离级别，它确保同一事务的多个实例在并发读取数据时，会看到同样的数据行。不过理论上，这会导致另一个棘手的问题：幻读（Phantom Read）。简单的说，幻读指当用户读取某一范围的数据行时，另一个事务又在该范围内插入了新行，当用户再读取该范围的数据行时，会发现有新的“幻读” 行。InnoDB 和 Falcon 存储引擎通过多版本并发控制MVCC机制解决了该问题。注：其实多版本只是解决不可重复读问题，而加上间隙锁（也就是这里所谓的并发控制）才解决了幻读问题。其实很多时候幻读我们是可以接受的。
4. Serializable（可串行化）：这是最高的隔离级别，它通过强制事务排序，使之不可能相互冲突，从而解决幻读问题。简言之，它是在每个读的数据行上加上共享锁。在这个级别，可能导致大量的超时现象和锁竞争。

用一个例子说明这几种隔离级别。假设数据表T中只有一列，其中一行的值为1，下面是按照时间顺序执行两个事务的行为：

我们来看看在不同的隔离级别下，事务A会有哪些不同的返回结果，也就是图里面V1、V2、V3的返回值分别是什么。

1. 若隔离级别是“读未提交”， 则V1的值就是2。这时候事务B虽然还没有提交，但是结果已经被A看到了。因此，V2、V3也都是2。
2. 若隔离级别是“读提交”，则V1是1，V2的值是2。事务B的更新在提交后才能被A看到。所以， V3的值也是2。
3. 若隔离级别是“可重复读”，则V1、V2是1，V3是2。之所以V2还是1，因为事务A还在自己的事务处理过程中，也就是事务A还没有提交事务，遵循的就是这个要求：事务在执行期间看到的数据前后必须是一致的。它解决了不可重复读的问题（即事务A读取到了事务B已经提交的修改的数据）
    
4. 若隔离级别是“可串行化”，则在事务B执行“将1改成2”的时候，会被锁住（事务B现在还不能修改数据，处于阻塞状态）。直到事务A提交后，事务B才可以继续执行。所以从A的角度看， V1、V2值是1，V3的值是2。

在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个SQL语句开始执行的时候创建的。这里需要注意的是，“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。

我们可以看到在不同的隔离级别下，数据库行为是有所不同的。Oracle数据库的默认隔离级别其实就是“读提交”，因此对于一些从Oracle迁移到MySQL的应用，为保证数据库隔离级别的一致，你一定要记得将MySQL的隔离级别设置为“读提交”。

总结来说，存在即合理，哪个隔离级别都有它自己的使用场景，你要根据自己的业务情况来定。我想你可能会问那什么时候需要“可重复读”的场景呢？我们来看一个数据校对逻辑的案例。

假设你在管理一个个人银行账户表。一个表存了每个月月底的余额，一个表存了账单明细。这时候你要做数据校对，也就是判断上个月的余额和当前余额的差额，是否与本月的账单明细一致。你一定希望在校对过程中，即使有用户发生了一笔新的交易，也不影响你的校对结果。这时候使用“可重复读”隔离级别就很方便。事务启动时的视图可以认为是静态的，不受其他事务更新的影响。

mysql8.0查看当前数据库的事务隔离级别: show variables like 'transaction_isolation';默认是RR。

Mysql中隔离级别的实现

其实在多个客户端并发操作同一张表数据的时候无非出现下面三种情况：

1. 读取、读取（这种都是读取，不会产生并发问题）
2. 读取、写入（这就产生上面介绍的几种问题：脏读、不可重复读、幻读）
3. 写入、写入（更新丢失）

数据库中设置相应的隔离级别就是解决了不同的读的问题。比如"读已提交"解决了脏读，“可重复读”解决了脏读，不可重复读的问题。这两种隔离级别在Mysql中是如何实现的?   就是利用MVCC(multi-version-concurrent-control)并发版本控制。

MVCC机制（用于解决读-写冲突的无锁并发控制）

1. 是什么？MVCC即多个不同版本的数据实现并发控制的技术（为数据加一个版本号），其基本思想是为每次事务生成一个新版本的数据，在读数据时选择不同版本的数据就可以实现对事务结果的完整性读取。
2. 能干嘛？  提高并发的读写性能。

它是这么说的：每个事务操作的时候会生成事务id（或者说事务的版本号）；每条记录都会保存两个隐藏列: trx_id(事务id）和roll_pointer(回滚指针)2个字段；每次操作都会生成—条undo log日志，回滚指针指向前一条记录。

查询的时候会读取出ReadView: [未提交的事务id]数组+生成的最大事务id，并根据readview从undo log日志中最新的记录依次往前找，进行事务id的比对，判断是否是可读的。

1. 如果当前记录: 事务id < 未提交事务的最小id，则可读
2. 如果当前记录: 未提交事务的最小id<=当前事务id<=事务的最大id，则判断事务站是否在未提交事务id的数组中，若在则不可读(只有自己可读)
3. 如果当前记录: 事务id>已提交事务的最天id，则不可读

下面通过一个例子说明他是如何实现“读已提交”和“可重复读” 两种隔离级别的：

MVCC只针对读已提交和可重复读，如果是读未提交，每次查询都取最新的记录即可。

上面体现了多版本的作用，多版本其实解决的只是“不可重复读的问题”，至于幻读问题，还需要结合间隙锁来解决。

下面通过一个例子来演示MySql中默认隔离级别RR下解决的问题（ps：下面这张表在行锁的演示中还会用到）。

表锁

MySQL的表级锁有两种模式:

1. 表共享读锁（Table Read Lock）
2. 表独占写锁（Table Write Lock）

常用的几个命令：

1. 查看那些表被加了锁：show open tables;   
2. 手动增加表锁：lock table 表名字 read/write, 表名字2 read/write, 其它;
3. 释放表锁：unlock tables;

下面是视频中的例子，通过这个例子来演示多个连接下，如果加了表锁会发生什么情况：

MyISAM在执行查询语句（SELECT）前，会自动给涉及的所有表加读锁，在执行增删改操作前，会自动给涉及的表加写锁。

MyISAM表进行操作，会有以下情况:

1. 对MyISAM表的读操作〈加读锁），不会阻塞其他进程对同一表的读请求，但会阻塞对同一表的写请求。只有当读锁释放后，才会执行其它进程的写操作。
2. 对MyISAM表的写操作（加写锁)，会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操
   作。

简而言之，就是读锁会阻塞写，但是不会阻塞读。而写锁则会把读和写都阻塞

可以通过检查table_locks_waited和table_locks_immediate状态变量来分析系统上的表锁定，执行SQL: show status like 'table%';

会有两个状态变量记录MySQL内部表级锁定的情况，两个变量说明如下:

1. Table_locks_immediate:产生表级锁定的次数，表示可以立即获取锁的查询次数，每立即获取锁值加1；
2. Table_ocks_waited:出现表级锁定争用而发生等待的次数(不能立即获取锁的次数，每等待一次锁值加1)，此值高则说明存在着较严重的表级锁争用情况;

此外，MyISAM的读写锁调度是写优先，这也是MyISAM不适合做写为主表的引擎。因为写锁后，其他线程不能做任何操作，大量的更新会使查询很难得到锁，从而造成永远阻塞，读取不到数据。

行锁

InnoDB与MyISAM的最大不同有两点:一是支持事务、二是采用了行级锁。

索引失效可能导致行锁变表锁：

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

间隙锁的危害：
因为Query执行过程中通过范围查找的话，他会锁定整个范围内所有的索引键值，即使这个键值并不存在。
间隙锁有一个比较致命的弱点，就是当锁定一个范围键值之后，即使某些不存在的键值也会被无辜的锁定，而造成在锁定的时候无法插入锁定键值范围内的任何数据。在某些场景下这可能会对性能造成很大的危害。

演示：

如何手动锁定一行？下面加的是写锁/排他锁

通过检查InnoDB_row_lock状态变量来分析系统上的行锁的争夺情况：show status like 'innodb_row_lock%';

1. lnnodb_row_lock_current_waits: 当前正在等待锁定的数量;
2. Innodb_row_lock_time(重要): 从系统启动到现在锁定总时长;
3. Innodb_row_lock_time_avg(重要):每次等待所花平均时间;
4. Innodb_row_lock_time_max:从系统启动到现在等待最常的一次所花的时间;
5. Innodb_row_lock_waits(重要):系统启动后到现在总共等待的次数;

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

优化建议：

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

Innodb存储引擎由于实现了行级锁定，虽然在锁定机制的实现方面所带来的性能损耗可能比表级锁定会要更高一些，但是在整体并发处理能力方面要远远优于MyISAM的表级锁定的。当系统并发量较高的时候，Innodb的整体性能和MyISAM相比就会有比较明显的优势了。但是，Innodb的行级锁定同样也有其脆弱的一面，当我们使用不当的时候，可能会让Inodb的整体性能表现不仅不能比MyISAM高甚至可能会更差。

MyISAM 与 InnoDB 的区别：

1.  事务支持：
   1. MyISAM强调的是性能，每次查询具有原子性 , 其执行速度比 InnoDB 类型更快，但是不提供事务支持。
   2. InnoDB提供事务支持事务，外部键等高级数据库功能。 具有事务(commit)、回滚(rollback)和崩溃修复能力(crash recovery capabilities)的事务安全(transaction-safe (ACID compliant))型表。
2. MyISAM 支持表级锁，而InnoDB 支持行级锁和表级锁，默认使用行级锁。 用户在操作MyISAM 表时，select，update，delete，insert 语句都会给表自动加锁。
3. InnoDB 支持 MVCC, 而 MyISAM 不支持。
4. InnoDB 支持外键，而 MyISAM 不支持
5. 表主键：
   1. MyISAM ：允许没有任何索引和主键的表存在，索引都是保存数据行的地址。
   2. InnoDB：如果没有设定主键或者非空唯一索引，就会自动生成一个 6 字节的主键(用户不可见)，数据是主索引的一部分，附加索引保存的是主索引的值。
6. InnoDB 不支持全文索引，而 MyISAM 支持。
7. 存储结构：
   1. MyISAM ：每个 MyISAM 在磁盘上存储成三个文件。第一个文件的名字以表的名字开始，扩展名指出文件类型。.frm 文件存储表定义。数据文件的扩展名为 .MYD (MYData) 。索引文件的扩展名是 .MYI (MYIndex) 。
   2. InnoDB：所有的表都保存在同一个数据文件中（也可能是多个文件，或者是独立的表空间文件），InnoDB 表的大小只受限于操作系统文件的大小，一般为 2GB

参考博文：https://www.cnblogs.com/gaosf/p/11142094.html这个博主对MySQL中涉及到的点进行了详细的分析。

【不积硅步，无以至千里；不积小流，无以成江海】