[大数据]MySQL事务和锁

作者：IT王小二

博客：https://itwxe.com

MySQL是怎么解决并发事务所产生的问题呢？又借助了哪些锁的思想呢？这篇小二给小伙伴们继续唠一唠MySQL的那些事。

一、事务是什么

事务是由一组SQL语句组成的逻辑处理单元，这些操作要么全部执行，要么全部不执行，是一个不可分割的工作单位。通常有下面4个特性，也就是咱程序猿俗称的ACID属性。

• 原子性(Atomicity)：事务是一个原子操作单元，其对数据的修改，要么全部执行，要么全部不执行。举个例子：情人节小二给女朋友转账520块，那么SQL中一共两个操作，小二的账户余额-520块，女朋友账户余额+520块，这一组转账操作，不能只执行小二的账户-520块，或者只执行女朋友账户余额+520块，只能都执行，或者都不执行。
• 一致性(Consistent)：在事务开始和完成时，数据都必须保持一致状态。一致性和原子性息息相关，即一组转账操作下来小二账户余额应该-520块，女朋友账户余额+520块，两人转账操作之后账户总金额是一致的。
• 隔离性(Isolation)：一个事务的执行不能被其他事务干扰，即每个事务都是独立的，不受其他事务的影响。简单来说就是一个事务(T1)处理过程的中间状态对其他事务(T2, T3…)是不可见的；同理，T2同样对T1和T3的中间状态不可见的。即只要小二的转账操作没完成，那么女朋友不管怎么查询结果都是原来的余额，而不会查询多出520块。
• 持久性(Durable)：事务完成之后，对数据的修改是永久性的，即便是在数据库系统遇到故障的情况下也不会丢失提交事务的操作。即只要小二转账成功了，数据就保存磁盘了。

二、并发事务所产生的问题

脏写或者更新丢失(Lost Update)

当两个或多个事务同一时间修改同一行，然后基于最初选定的值进行业务操作更新该行时，由于每个事务都不知道其他事务的存在，就会发生丢失更新问题。

简单来说就是最后的更新覆盖了由其他事务所做的更新。

脏读(Dirty Reads)

一个事务读到了其他事务已经修改但是未提交的数据，未提交意味着这些数据可能会回滚，也就是可能最终不一定会存到数据库中，所以读出来的数据是无效的。

不可重复读(Non-Repeatable Reads)

一个事务在读取某些数据后的某个时间点，再次读取以前读过的那批数据，却发现其读出的数据已经发生了改变，可能会受到其他事务的影响，比如其他事务改了这批数据并提交了。通常针对数据更新(UPDATE)操作或者删除(DELETE)操作。

简单来说就是在一个事务中，相同查询语句在不同时刻查询出来的结果不一致，可能是结果字段值不一致，也可能是少了行数据。

幻读(Phantom Reads)

对比不可重复读，幻读是针对数据新增(INSERT)来说的，在同一事务下，在读取某些数据后的某个时间点，再次读取以前读过的那批数据，第二次的SQL语句返回了之前不存在的行。

简单来说就是事务A读取到了其他事务提交的新增数据。

再来区分一下经常搞混的不可重复读和幻读。

• 不可重复读：说的是原来存在的记录A，记录A从A变成了记录B。
• 幻读：出现了原来不存在的记录。

当然还是区分不明显的小伙伴可以结合五、行锁与事务隔离级别案例分析理解理解，理论结合实践，nice~

三、事务隔离级别

并发事务产生的脏读、不可重复读、幻读都是数据库读取的一致性，问题，所以数据库提供了一定的事务隔离级别来解决产生的问题。

MySQL数据库默认的隔离级别为可重复读(repeatable-read)，也就是我们常说的RR级别。

查看事务隔离级别：show variables like 'tx_isolation';

设置事务隔离级别，例如设置隔离级别为读未提交：

• 仅对当前会话生效，立即生效：set session transaction isolation level read uncommitted;或者set tx_isolation = 'read-uncommitted';
• 对全局会话生效，需要退出会话后生效：set global transaction isolation level read uncommitted;

用Spring开发程序时，如果不设置隔离级别默认用MySQL设置的隔离级别，如果Spring设置了就用设置的隔离级别。

四、锁分类

锁是计算机协调多个进程或者线程并发访问同一资源的机制，而对于数据库来说数据就是一种需要用户共享的资源，怎么保证数据的并发访问一致性和高效性是数据库需要解决的问题。

按不同分类有以下分类。

• 从性能上来分，分为乐观锁和悲观锁。
  • 乐观锁比较乐观，乐观锁假设数据一般情况不会造成冲突，多线程同时对同一行数据修改的时候，在数据进行提交更新的时候，才会正式对数据的冲突与否进行检测，如果冲突，则返回给用户异常信息，让用户决定如何去做。
  • 悲观锁比较悲观，多线程同时对同一行数据修改的时候，最终只有一个线程修改成功。
• 从对数据库操作的类型分，分为读锁和写锁(都属于悲观锁)。
  • 读锁(共享锁，S锁(Shared))：针对同一份数据，多个读操作可以同时进行而不会互相影响。
  • 写锁(排它锁，X锁(eXclusive))：当前写操作没有完成前，它会阻断其他写锁和读锁。
• 从对数据操作的粒度分，分为表锁和行锁。

1. 表锁

每次操作锁住整张表。开销小，加锁快，不会出现死锁，锁定粒度大，发生锁冲突的概率最高，并发度最低，一般用在整表数据迁移的场景。

基本操作

• 手动增加表锁：lock table 表名称 read/write,表名称2 read/write;
• 查看表上加过的锁：show open tables;
• 删除表锁：unlock tables;

实操一下

-- 创建示例表
CREATE TABLE `test_myisam_lock` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) NOT NULL,
  `age` int(11) NOT NULL,
  PRIMARY KEY (`id`)
) ENGINE = MyISAM DEFAULT CHARSET = utf8;

-- 插入几条数据
INSERT INTO `blog_test`.`test_myisam_lock` (`id`, `name`, `age`) VALUES (1, 'itwxe', 18);
INSERT INTO `blog_test`.`test_myisam_lock` (`id`, `name`, `age`) VALUES (2, 'Lee Patel', 62);
INSERT INTO `blog_test`.`test_myisam_lock` (`id`, `name`, `age`) VALUES (3, 'Sakurai Mio', 55);
INSERT INTO `blog_test`.`test_myisam_lock` (`id`, `name`, `age`) VALUES (4, 'Tan Xiuying', 42);
INSERT INTO `blog_test`.`test_myisam_lock` (`id`, `name`, `age`) VALUES (5, 'Cheng Yunxi', 47);

1、加读锁

本文表格中序号代表两个session中SQL的执行顺序，同一行为从左往右执行的语句。图中已标注当前示例SQL执行顺序，后续不再截图说明。

对MyISAM表的读操作(加读锁)，不会阻塞其他进程对同一表的读请求；但会阻塞对同一表的写请求，当前线程无法执行写操作，其他线程进入等待状态，只有当读锁释放后，才会执行其它进程的写操作。

2、加写锁

简单来说：对MylSAM表的写操作(加写锁)，不会阻塞当前进程对表的读写操作；但是会阻塞其他进程对同一表的读和写操作，只有当写锁释放后，才会执行其它进程的读写操作。

2. 行锁

每次操作锁住一行数据，开销大，加锁慢，会出现死锁，锁定粒度最小，发生锁冲突的概率最低，并发度最高。

同时InnoDB与MyISAM最大的两点不同就是支持事务和支持行级锁。

基本操作

-- 创建示例表
CREATE TABLE `account` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `name` varchar(20) DEFAULT NULL,
  `balance` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

-- 插入几条数据
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (1, 'itwxe', 1000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (2, 'Kenneth Adams', 2000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (3, 'Takada Daichi', 3000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (4, 'Anne Russell', 4000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (5, 'Jia Yuning', 5000);

默认的RR隔离级别下示例，即可重复读(repeatable-read)。

当然啦，小二这里写的只有两个会话，如果有很多个session同时更新一行数据也是一样进入等待状态。

简单来说：在非串行化事务隔离级别下，InnoDB在执行查询语句select时不会加锁，但是update、insert、delete操作会加行锁。

当然，当查询语句也需要加锁也是可以的，使用 select ... for update。

select * from account where id = 1 for update;

此时当前会话对于id = 1的行可以进行增删改查操作，其它会话不能对id = 1行进行操作。只有等待当前会话释放锁(提交/回滚事务)后才能够操作记录id = 1的行。

五、行锁与事务隔离级别案例分析

行锁支持事务所以当然就得结合事务隔离级别来分析实操一下。

1. 读未提交

首先将示例账户余额还原到1000，update account set balance = 1000 where id = 1;。

可以看到，读未提交隔离级别下，第5行session读取到的账户余额就是2000了，这个时候如果Java应用程序使用2000作为判断了某些业务操作，例如判断是否可以购买一个2000的商品，此时session又还没有扣减余额，那么当session2因为某些原因回滚了，此时id为1的用户余额就是 -1000 块了，这是明显不合理的；并且实际开发中一定不要使用Java程序计算后直接将值更新到数据库，这样会造成脏写，例如Java程序计算值后账户余额为零，那么执行update account set balance = 0 where id = 1;的话问题就更大了。

为了解决这个问题就要用到读已提交的隔离级别了。

2. 读已提交

首先将示例账户余额还原到1000，update account set balance = 1000 where id = 1;。

可以看到已经解决了脏读的问题，但是在session2提交后出现了不可重复读的问题，不可重复读会让我们在编写Java应用代码的时候很难编写，而不可重复读就得靠可重复读的隔离级别来解决了。

3. 可重复读

首先将示例账户余额还原到1000，update account set balance = 1000 where id = 1;。

所以，可以看到其实MySQL并没有完全解决幻读的问题，在RR级别下当MySQL有可能会出现幻读问题。

当然我们实际开发通常也不会这样去操作，因为id = 6这个对当前session是不可见的，所以通常不会直接修改到其他session插入的记录。

所以MySQL默认的事务隔离级别就是RR级别，并发高且能解决99.99%的业务场景。

4. 串行化

首先将示例账户余额还原到1000，update account set balance = 1000 where id = 1;。

可以看到串行化隔离级别下，使用的是排它锁，锁定记录的增删改查都会收到影响进入等待执行状态。

所以，串行化隔离级别下不会有幻读的问题，当然效率也最低，通常实际项目开发中都不会使用。

六、行锁详解

1. 记录锁、间隙锁、临键锁

行锁有三个类型，分别是记录锁、间隙锁、临键锁，记录锁只锁定一行记录，而间隙锁和临键锁都是锁定一个范围的记录行。

记录锁(Record Locks)

记录锁锁定一行记录的已经在锁分类中演示过了 id = 1 的场景，不唠叨了。

间隙锁(Gap Locks)

间隙锁指的是锁的是两个值之间的间隙，可以解决RR级别下一些情景的幻读问题。

-- 再插入几条数据演示间隙锁和临键锁
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (13, 'itwxe.com', 13000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (18, 'zhangsan', 18000);
INSERT INTO `blog_test`.`account` (`id`, `name`, `balance`) VALUES (25, 'lisi', 25000);

插入数据后id就产生了(6, 13), (13, 18), (18, 25), (25, 正无穷) 这四个空间间隙。

下面使用RR事务隔离级别，set tx_isolation='repeatable-read';。

可以看到测试中产生锁定的范围为(6, 13]，也就是说间隙锁锁定的范围是小范围(id=8)前一条行记录(id=6)的开区间到大范围(id=13)的后一条记录，左开右闭区间。

可以看到间隙锁在减少了某些情况下幻读的发生，通过对间隙加锁让间隙内在session1提交(回滚)事务之前其他session都无法进行插入或者修改任何数据。

间隙锁是在可重复读隔离级别下才会生效。

临键锁(Next-key Locks)

临键锁可以说是特殊的间隙锁，即行锁和间隙锁的结合，可以理解为间隙锁中包含记录行。

目前存在(6, 13), (13, 18), (18, 25), (25, 正无穷) 这四个空间间隙。

下面使用RR事务隔离级别，set tx_isolation='repeatable-read';。

可以看到临键锁锁定的范围是(13,正无穷]。同样是左开右闭，取不到13而取得到正无穷。

2. 无索引行锁升级表锁

看到这里都是耐心的小伙伴啦，InnoDB的行锁是针对索引加的锁，不是针对记录加的锁。并且该索引不能失效，否则会从行锁升级为表锁。

所以，如果对非索引字段更新，行锁会升级成表锁，升级成表锁后任意行的写操作都会阻塞，直到表锁被释放。

3. 行锁分析

可以通过检查innodb_row_lock状态变量来分析MySQL行锁的情况。

show status like 'innodb_row_lock%'

• Innodb_row_lock_current_waits：当前正在等待锁定的数量
• Innodb_row_lock_time：从MySQL启动到现在锁定总时间长度
• Innodb_row_lock_time_avg：每次等待的平均时间
• Innodb_row_lock_time_max：MySQL启动到现在最长的一次等待时间
• Innodb_row_lock_waits：MySQL启动后到现在总共等待的次数

当等待次数很多，并且每次等待时长也很长时，就要分析系统中为什么会有这么多的等待，然后根据分析结果着手制定优化计划。

4. 系统库与锁相关的表

MySQL系统库中几个与锁相关的表，有时开发中debug调试碰到一直卡着SQL语句不执行，这时候完全有可能是其他小伙伴也在调试这一行数据，然后一直锁定了那行数据所以你就调试不下去了，那么咋办嘞？

MySQL给我们提供了表来查询，只要kill掉其他小伙伴的事务自然你就可以调试了，不过轻易不要尝试，因为你kill掉那个事务后其他小伙伴如果没调试完那么就白调试了，所以被揍了小二概不负责😂

‐‐ 查看事务
select * from INFORMATION_SCHEMA.INNODB_TRX;

‐‐ 查看锁
select * from INFORMATION_SCHEMA.INNODB_LOCKS;

‐‐ 查看锁等待
select * from INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

‐‐ 释放锁，trx_mysql_thread_id是INNODB_TRX表中查询的信息的值，例如`kill 394`，kill掉的事务无法提交也无法回滚，会包ERROR错误
kill trx_mysql_thread_id;

‐‐ 查看锁等待详细信息
show engine innodb status\G;

5. 死锁

大多数情况下MySQL可以自动检测死锁并回滚产生死锁的那个事务，但是有些情况MySQL没法自动检测死锁。

6. 锁优化建议

• 尽可能让所有数据检索都通过索引来完成，避免无索引行锁升级为表锁。
• 尽可能减少检索条件范围，避免间隙锁。
• 尽量控制事务大小，减少锁定资源量和时间长度，涉及事务加锁的sql尽量放在事务最后执行。