最近，在一次 mysql 死锁的生产事故中，我发现，关于 mysql 的锁、事务等等，我所知道的东西太碎了，所以，我试着用几个例子将它们串起来。具体做法就是通过不断地问问题、回答问题，再加上“适当”的比喻，来逐步构建脑子里的“知识树”。
需要提醒一下，这篇博客并不适合小白，因为你需要先了解排它锁、共享锁、事务，最重要的是你需要知道事务中的锁是什么时候加上、什么时候打开的。而这篇博客更多的是希望把这些碎片化的知识给连接起来。
项目环境
mysql 版本：5.7.28-winx64
OS：win 10
数据库脚本：
DROP TABLE IF EXISTS `demo_user`;
CREATE TABLE `demo_user` (
`id` varchar(32) NOT NULL COMMENT '用户id',
`name` varchar(16) NOT NULL COMMENT '用户名',
`gender` tinyint(1) DEFAULT '0' COMMENT '性别',
`age` int(3) unsigned DEFAULT NULL COMMENT '用户年龄',
`gmt_create` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录创建时间',
`gmt_modified` timestamp NULL DEFAULT NULL COMMENT '记录最近修改时间',
`deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
`phone` varchar(11) NOT NULL COMMENT '电话号码',
PRIMARY KEY (`id`),
KEY `idx_phone` (`phone`),
KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('222','zzs001',0,18,'2021-12-13 15:11:03','2021-12-13 09:59:12',0,'188******26');
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('111','zzf001'0,18,'2001-08-27 11:00:11','2001-08-27 11:00:13',0,'188******22');
脏读
准备工作
在讲脏读之前，我们先开启两个会话，并把事务隔离级别更改为读未提交（read uncommitted）。这时，id 为 222 的用户初始年龄为 18。
万事俱备，我们开始吧。
什么是脏读
脏读，就是读到了其他会话还没有提交的修改。下面用例子说明：
可以看到，会话 2 修改了 id 为 222 的用户，在还没提交或回滚事务之前，会话 1 就读到了这些改动。
脏读的本质就是，还没结束的写操作被读操作分割了。所以，为了解决脏读，就必须让写操作不可被读操作分割（当然，也不能被其他写操作分割），即保证所谓的原子性。
如何解决脏读
那么，应该如何实现呢？这里给出两种方案。
第一种，给读增加锁。为了保证写操作的原子性，从更新操作开始到事务结束（注意，不是事务开始到事务结束），会话 2 都应该锁着 id 为 222 的记录，会话 1 的读操作要等会话 2 的事务结束后才能执行。上面的例子中，我们理所当然地会认为是会话 2 的写操作没有加排它锁导致的脏读，然而并非如此，通过SELECT * FROM information_schema.INNODB_TRX;可以发现，会话 2 已经锁住了 id 为 222 的记录，但会话 1 的读操作并没有等待，为什么呢？根本原因在于会话 1 的读是无锁读，在读未提交的事务隔离级别中，无锁读不需要等待写操作。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，因为会话 2 的更新操作还没结束，所以，会话 1 需要一直等待，直到会话 2 的事务结束，这就避免了脏读的问题。你可能会觉得奇怪，实际项目好像不是这样的吧？没错，因为我们用的更多的是第二种方案。
第二种方案，将事务隔离级别更改为读已提交（read committed）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现脏读。需求刁钻但合理，于是，就有了第二种方案。如下：
可以看到，会话 2 的更新操作还没结束，会话 1 就读到了同一条记录，结果却没有产生脏读。如何实现的呢？
这里我说说自己的理解，可能并不严谨。逻辑上有点像 java 中的CopyOnWriteArrayList，当事务隔离级别为已提交时，不会在实际记录上进行写操作，而是将需要修改的记录缓存一份进行更改，事务提交时才把这部分缓存刷入实际记录，而这个过程，其他会话可以正常读实际记录，而不会读到修改中的数据。
不可重复读
准备工作
在讲不可重复读之前，我们可以把事务隔离级别设置为读未提交（read uncommitted），也可以设置为读已提交（read committed）。
什么是不可重复读
不可重复读，就是在同一个事务中，多次读相同的记录但读到了不同的结果。下面用例子说明：
可以看到，会话 1 第一次读 id 为 222 的用户年龄为 18，在事务还没结束之前，会话 2 将他的年龄更改为 19，会话 1 再次读就会出现前后不一致的情况。
不可重复读的本质就是，还没结束的读操作被写操作分割了。所以，为了解决不可重复读，就必须让读操作不可被写操作分割，即保证所谓的原子性。
如何解决不可重复读
那么，应该如何实现呢？和解决脏数据一样，这里也给出两种方案。
第一种方案，给读增加锁来。为了保证读操作的原子性，从读操作开始到事务结束（注意，不是事务开始到事务结束），会话 1 都应该锁着 id 为 222 的记录，会话 2 的写操作要等会话 1 的事务结束后才能执行。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，会话 2 的写操作需要等待会话 1 的事务结束才能执行，在事务结束之前，会话 1 读几次数据都不会出现不可重复读。
第二种方案，将事务隔离级别更改为可重复读（repeatable read）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现不可重复读。于是，就有了第二种方案。如下：
可以看到，会话 1 的读操作并没有加锁，会话 2 的写操作也不需要等待，最终却没有产生不可重复读。如何实现的呢？
这里我还是说说自己不严谨的理解。当第一次读到 id 为 222 的记录时，mysql 会把这条记录放在当前事务的缓存区里，下次读这条数据的时候直接从缓存拿就好，不需要去读实际记录，所以，其他会话的写操作并不需要等待。这种读被称为快照读，如果读已提交中的写是 copy on write，那可重复读的读就是 copy on read。
幻读
未完待续。
结语
以上只是自己对 mysql 锁、事务的一点点思考。因为我并没有看过底层的逻辑，所以都是一些抽象层面的解读。如有错误，欢迎指正。
最后，感谢阅读。
参考资料
本文为原创文章，转载请附上原文出处链接：最近，在一次 mysql 死锁的生产事故中，我发现，关于 mysql 的锁、事务等等，我所知道的东西太碎了，所以，我试着用几个例子将它们串起来。具体做法就是通过不断地问问题、回答问题，再加上“适当”的比喻，来逐步构建脑子里的“知识树”。
需要提醒一下，这篇博客并不适合小白，因为你需要先了解排它锁、共享锁、事务，最重要的是你需要知道事务中的锁是什么时候加上、什么时候打开的。而这篇博客更多的是希望把这些碎片化的知识给连接起来。
项目环境
mysql 版本：5.7.28-winx64
OS：win 10
数据库脚本：
DROP TABLE IF EXISTS `demo_user`;
CREATE TABLE `demo_user` (
`id` varchar(32) NOT NULL COMMENT '用户id',
`name` varchar(16) NOT NULL COMMENT '用户名',
`gender` tinyint(1) DEFAULT '0' COMMENT '性别',
`age` int(3) unsigned DEFAULT NULL COMMENT '用户年龄',
`gmt_create` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '记录创建时间',
`gmt_modified` timestamp NULL DEFAULT NULL COMMENT '记录最近修改时间',
`deleted` tinyint(1) DEFAULT '0' COMMENT '是否删除',
`phone` varchar(11) NOT NULL COMMENT '电话号码',
PRIMARY KEY (`id`),
KEY `idx_phone` (`phone`),
KEY `idx_name` (`name`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('222','zzs001',0,18,'2021-12-13 15:11:03','2021-12-13 09:59:12',0,'188******26');
insert into `demo_user`(`id`,`name`,`gender`,`age`,`gmt_create`,`gmt_modified`,`deleted`,`phone`) values ('111','zzf001'0,18,'2001-08-27 11:00:11','2001-08-27 11:00:13',0,'188******22');
脏读
准备工作
在讲脏读之前，我们先开启两个会话，并把事务隔离级别更改为读未提交（read uncommitted）。这时，id 为 222 的用户初始年龄为 18。
万事俱备，我们开始吧。
什么是脏读
脏读，就是读到了其他会话还没有提交的修改。下面用例子说明：
可以看到，会话 2 修改了 id 为 222 的用户，在还没提交或回滚事务之前，会话 1 就读到了这些改动。
脏读的本质就是，还没结束的写操作被读操作分割了。所以，为了解决脏读，就必须让写操作不可被读操作分割（当然，也不能被其他写操作分割），即保证所谓的原子性。
如何解决脏读
那么，应该如何实现呢？这里给出两种方案。
第一种，给读增加锁。为了保证写操作的原子性，从更新操作开始到事务结束（注意，不是事务开始到事务结束），会话 2 都应该锁着 id 为 222 的记录，会话 1 的读操作要等会话 2 的事务结束后才能执行。上面的例子中，我们理所当然地会认为是会话 2 的写操作没有加排它锁导致的脏读，然而并非如此，通过SELECT * FROM information_schema.INNODB_TRX;可以发现，会话 2 已经锁住了 id 为 222 的记录，但会话 1 的读操作并没有等待，为什么呢？根本原因在于会话 1 的读是无锁读，在读未提交的事务隔离级别中，无锁读不需要等待写操作。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，因为会话 2 的更新操作还没结束，所以，会话 1 需要一直等待，直到会话 2 的事务结束，这就避免了脏读的问题。你可能会觉得奇怪，实际项目好像不是这样的吧？没错，因为我们用的更多的是第二种方案。
第二种方案，将事务隔离级别更改为读已提交（read committed）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现脏读。需求刁钻但合理，于是，就有了第二种方案。如下：
可以看到，会话 2 的更新操作还没结束，会话 1 就读到了同一条记录，结果却没有产生脏读。如何实现的呢？
这里我说说自己的理解，可能并不严谨。逻辑上有点像 java 中的CopyOnWriteArrayList，当事务隔离级别为已提交时，不会在实际记录上进行写操作，而是将需要修改的记录缓存一份进行更改，事务提交时才把这部分缓存刷入实际记录，而这个过程，其他会话可以正常读实际记录，而不会读到修改中的数据。
不可重复读
准备工作
在讲不可重复读之前，我们可以把事务隔离级别设置为读未提交（read uncommitted），也可以设置为读已提交（read committed）。
什么是不可重复读
不可重复读，就是在同一个事务中，多次读相同的记录但读到了不同的结果。下面用例子说明：
可以看到，会话 1 第一次读 id 为 222 的用户年龄为 18，在事务还没结束之前，会话 2 将他的年龄更改为 19，会话 1 再次读就会出现前后不一致的情况。
不可重复读的本质就是，还没结束的读操作被写操作分割了。所以，为了解决不可重复读，就必须让读操作不可被写操作分割，即保证所谓的原子性。
如何解决不可重复读
那么，应该如何实现呢？和解决脏数据一样，这里也给出两种方案。
第一种方案，给读增加锁来。为了保证读操作的原子性，从读操作开始到事务结束（注意，不是事务开始到事务结束），会话 1 都应该锁着 id 为 222 的记录，会话 2 的写操作要等会话 1 的事务结束后才能执行。所以，我们需要给读加上锁（共享锁和排它锁均可，但为了并发读，建议用共享锁），如下：
可以看到，会话 2 的写操作需要等待会话 1 的事务结束才能执行，在事务结束之前，会话 1 读几次数据都不会出现不可重复读。
第二种方案，将事务隔离级别更改为可重复读（repeatable read）。第一种方案中，读写是串行的，然而，我们既要读写并行，又不想出现不可重复读。于是，就有了第二种方案。如下：
可以看到，会话 1 的读操作并没有加锁，会话 2 的写操作也不需要等待，最终却没有产生不可重复读。如何实现的呢？
这里我还是说说自己不严谨的理解。当第一次读到 id 为 222 的记录时，mysql 会把这条记录放在当前事务的缓存区里，下次读这条数据的时候直接从缓存拿就好，不需要去读实际记录，所以，其他会话的写操作并不需要等待。这种读被称为快照读，如果读已提交中的写是 copy on write，那可重复读的读就是 copy on read。
幻读
未完待续。
结语
以上只是自己对 mysql 锁、事务的一点点思考。因为我并没有看过底层的逻辑，所以都是一些抽象层面的解读。如有错误，欢迎指正。
最后，感谢阅读。
参考资料
本文为原创文章，转载请附上原文出处链接：https://www.cnblogs.com/ZhangZiSheng001/p/15727027.html