【MySQL】事务？隔离级别？锁？详解MySQL并发控制机制

1.先理清一下概念

2.锁

2.1.分类

2.2.表锁

2.3.行锁（MVCC）

2.4.间隙锁

2.5.行锁变表锁

2.6.强制锁行

1.先理清一下概念

所谓并发控制指的是在对数据库进行并发操作时如何保证数据的一致性和正确性。在数据库中与并发控制相关的概念有如下几个：

事务
隔离界别
锁

这几个概念大家应该都知道，但是我猜很多人没有把它们串在一起搞明白他们之间的关系，导致这三个概念各是各的，造成记忆负担，最后对整个数据库并发控制的体系也云里雾里的。

锁与事务的关系：

在计算机科学中，做并发控制都是用的“标志位”来实现的，说直白一点就是锁，我们基本上可以说计算机科学中并发控制的底层都是锁的思想。在数据库中也不例外，也是通过锁来实现并发控制的。使用上锁之后，整个数据库的读写都会对外呈现出一些特质，这些特质就是事务（ACID），原子性、一致性、隔离性、持久性。

锁与隔离级别的关系：

当然锁有很多，在数据库中有行锁、表锁、读锁、写锁等等......不同级别的锁，ACID这些特质的强弱不同，这个强弱的级别就是“隔离级别”。

所以综合起来说就是用锁来实现并发控制，对外会呈现出事务（ACID），锁的级别的不同，ACID的强弱也不同，隔离级别对应也不同。

三个东西的关系理清楚后，来回顾一下事务和隔离级别的具体内容。

事务：

事务是为了保证SQL之间不产生脏数据。innodb中默认没有被包裹在事务中的一个单条SQL就是一个事务。事务是一类特征的总称，合起来为ACID：

原子性 (Atomicity):一个事务是一个不可分割的工作单元；事务中的所有操作要么全部成功执行，要么全部不执行。如果事务中的任何部分失败，则整个事务将被回滚到事务开始前的状态。
一致性 (Consistency):在事务开始和结束时，数据库都必须处于一致状态。这意味着事务的执行不会违反任何数据库约束或规则，并且会保持业务逻辑上的一致性。一旦事务完成，它应该使数据库从一个有效状态变为另一个有效状态。
隔离性 (Isolation):并发执行的多个事务之间互不干扰，如同它们是按顺序独立执行一样。这防止了脏读（读取未提交的数据）、不可重复读（在同一事务内多次读取同一数据时结果不同）和幻读（在事务中多次执行相同的查询时，由于其他已提交事务的插入或删除操作导致结果集发生变化）等现象。
持久性 (Durability):当事务成功提交后，其对数据库所做的修改将会永久保存，即使系统发生故障（如崩溃、重启等）也不会丢失这些修改。持久性通常是通过日志记录和恢复机制来保证的。

隔离级别：

事务内具有原子性，但是事务间不具有原子性，并发情况下，多事务间仍然会存在脏数据的问题。

1、脏读：事务A读取了事务B更新的数据，然后B回滚操作，那么A读取到的数据是脏数据。

2、不可重复读：事务 A 多次读取同一数据，事务 B 在事务A多次读取的过程中，对数据作了更新并提交，导致事务A多次读取同一数据时，结果不一致。

3、幻读：系统管理员A将数据库中所有学生的成绩从具体分数改为ABCDE等级，但是系统管理员B就在这个时候插入了一条具体分数的记录，当系统管理员A改结束后发现还有一条记录没有改过来，就好像发生了幻觉一样，这就叫幻读。

隔离级别就是为了保证事务之间不产生脏数据。

2.锁

2.1.分类

按照对数据的操作类型分类，分为：读锁、写锁。

按照对数据操作的粒度分类，分为：行锁、表锁、

表锁：

开销小、加锁快，无死锁，锁的粒度大，发生锁冲突的概率最高，并发度最低。

读锁：

又叫共享锁，针对同一份数据，多个读操作可以同时进行而不互相影响。针对被锁表，所有客户端都可以进行读操作，所有客户端都无法进行写操作，加锁方和其他客户端的区别是，加锁方直接不允许进行写操作，而其他客户端的写操作允许进行，只是会被阻塞挂起。锁解开后，所有挂起的操作线程会去重新争抢资源。

写锁：

又叫排它锁，当前写操作没有完成前，它会阻断其他写锁和读锁。针对被锁表，加锁方可以读写，其他客户端不行。其他客户端的写操作会直接失败，读操作会被阻塞挂起，解锁以后，被挂起的线程会重新去争抢资源。

保护机制：

读锁、写锁中，加锁方都只能读当前被自己锁定的表，这是MySQL的一个保护机制，为的就是强制要求加锁方给出一个说法，到底准备锁多久，不给说法不让走。

MySQL中不同引擎支持不同级别的锁，myIsam支持表锁，innodb支持行锁。

2.2.表锁

表锁，我们当然是要基于使用表锁的存储引擎来聊，也就是基于myIsam引擎。

myIsam引擎中的读写锁是自动加的。

myIsam引擎在解锁后的阻塞队列中进行读写锁调度是写优先，这样一旦阻塞队列中大量都是写操作，那么读操作会很难得到锁，变得很慢，从而造成永久堵塞。

当然除了自动加锁，表锁可以通过指令来加锁。

查看所有锁：

show open tables

解锁：

解铃还须系铃人，只有加锁方能解锁。

unlock  tables

加读锁:

lock table 表名 read

加写锁

lock table 表名 write

2.3.行锁（MVCC）

表锁，我们当然是要基于使用表锁的存储引擎来聊，也就是基于innodb引擎。innodb和myIsam最大的不同有两点，一是支持事务，二是采用了行级锁。innodb下读写都是自动加行锁，这没有什么好说的。但是行锁因为粒度太细了，会影响效率的，innodb没有傻傻的只用了行锁，还给出了行锁的优化方案——MVCC。

MVCC，多版本并发控制，本质上就是使用行锁锁定数据。

并发控制有几种处理方法，

第一种：基于锁的并发控制，程序员B开始修改数据时，给这些数据加上锁，程序员A这时再读，就发现读取不了，处于等待情况，只能等B操作完才能读数据，这保证A不会读到一个不一致的数据，但是这个会影响程序的运行效率。
第二种：MVCC，每个用户连接数据库时，看到的都是某一特定时刻的数据库快照，在B的事务没有提交之前，A始终读到的是某一特定时刻的数据库快照，不会读到B事务中的数据修改情况，直到B事务提交，才会读取B的修改内容。

MVCC的使用：

MySQL的MVCC是通过手动提交来实现的，数据库默认开启自动提交，通过set autocommit=0可以关闭自动提交。

关闭后每次执行sql以后，通过commit命令来手动提交，才会对数据库产生影响，否则只会对当前操作方的数据快照有影响。innodb引擎中，其他客户端想查看到最新的数据情况也必须通过commit指令来做一次同步（因为innodb默认隔离级别为可重复读）。

当一个客户端修改某行数据，未commit前，其他客户端对该行数据的修改会阻塞挂起，直到先改那个用户commit为止。