12 | 本地事务如何实现隔离性？
荧光笔
直线
曲线- 深入了解
- 翻译
- 解释
- 总结
本文深入探讨了数据库本地事务的隔离性实现原理和隔离级别的特点。首先介绍了隔离性与并发的关系以及数据库提供的三种锁：写锁、读锁和范围锁。随后详细介绍了本地事务的四种隔离级别：可串行化、可重复读、读已提交和读未提交，以及它们可能出现的问题和影响。文章还提到了现代数据库为用户提供不同隔离级别选项的目的，以及数据库实现隔离性与吞吐量之间的平衡。此外，还介绍了MVCC（Multi-Version Concurrency Control）的基础原理，以及乐观加锁和悲观加锁策略。总之，本文内容深入浅出，适合读者快速了解数据库事务隔离性的实现原理和隔离级别的特点。
请先领取课程
全部留言(39)
- 最新
- 精选
L周老师，有个疑问：范围锁可以阻塞其他事物的读锁和写锁。但是为何在串行化的隔离级别下，需要三个锁都加上？只加范围锁不行吗？作者回复: 这个问题很好。 文中强调过的X、S、Range三种锁是基于理论的描述，而不是基于具体某种数据库。这里的关键区别是具体数据库可以选择自己可能的方式去实现范围锁，以达到进一步的细分功能或提升性能等目的。 以MySQL/InnoDB为例，文中提到它的RR级别也没有幻读问题，原因是MySQL有两种范围锁的实现，分别是间隙锁（Gap Lock）和后码锁（Next-Key Lock）。 Gap Lock在RR级别的只读事务中出现，只锁定记录之间的空隙而不锁定记录本身，这点使得RR级别只读事务也没有幻读问题，而Next-key Lock则同时锁定记录本身和记录间的间隙。 所以，在理论描述写读写锁+范围锁全部加上是合适的。在具体数据库中实践中则有宽松点的余地，你可以认为只锁了一个Next-key Lock，也可以认为是同时锁了Record Lock + Gap Lock，这两者其实是等价的。
2020-12-14878
zhanyd隔离级别: RED UNCOMMITTED（未提交读） 在RED UNCOMMITTED级别，事务中的修改，即使没提交，对其他事务也是可见的。事务可以读取未提交的数据，这被称为“脏读”（Dirty Read），因为读取的很可能是中间过程的脏数据，而不是最终数据。 RED COMMITTED（提交读） 大多数数据库系统默认的隔离级别都是RED COMMITTED，但是MYSQL不是。RED COMMITTED说的是，一个事务只能读到其他事务已经提交的数据，所以叫提交读。这个事务级别也叫做不可重复读（nonrepeatableread），因为两次同样的查询，可能会得到不同的结果。 REPEATABLE READ（可重复读） REPEATABLE READ解决了脏读的问题。该级别保证了在同一事务中多次读取同样的记录结果是一致的。但是无法解决幻读的问题，所谓幻读，指的是当某个事务再读取某个范围内的记录时，另外一个事务又在该范围内插入了新的记录，当之前的事务再次读取该范围内的记录时，发现多了一行，会产生幻行。 SERIALIZABLE（可串行化） SERIALIZABLE是最高级别的隔离。它通过强制事务串行执行，避免了前面说的幻读的问题。简单来说，SERIALIZABLE会在读取的每一行数据上都加锁，所以可能导致大量的超时和锁争用的问题。 MVCC是一种读取优化策略，它在读取时不需要加锁的情况下，实现了提交读和可重复读的隔离级别。 可重复读：总是读在事务启动前就已经提交完成的数据。 提交读：总是读已经提交完成的数据。作者回复: 很好的总结
2020-12-14244- 饭老师这几篇acid的文章是我看过的写得最通俗易懂又不乏深度的文章。这么好的系列，居然还是免费，逆天了。纸质书什么时候出版，我要买一本
作者回复: 先感谢支持哈
2021-03-128 
Demon.Lee四类隔离级别，我学的时候就是背下来的，泪奔T﹏T作者回复: 我上大学的时候也是背下来的：）
2020-12-218
Wacky小恺在软件开发的发展历程中，“提供简洁的API”始终贯穿至今，因此本文中提到的透明事务，在我看来对普通开发人员的使用层面是完全有必要的。 但是作为开发人员，一定要有精益求精的品质，也许在日常使用中已经习惯了使用简洁的API来实现强大的功能。但如果遇到棘手的问题，或者需要自己思考解决方案的场景，那么“内功”就能显露出它的威力。作者回复: 赞成。
2020-12-157
朱坤周老师，您好。您在 【读已提交】这节的描述中提到: 读已提交对事务涉及到的数据加的写锁，会一直持续到事务结束，但加的读锁在查询操作完成后就马上会释放。 对于这节的例子，我有疑惑，我现在的理解是，T1已经拿到了写锁，T2的更新操作(需要写锁)应该被阻塞，直到T1事务结束。所以 T1 中第二次查询的结果应该是不变的。。请教下是我对 写锁的理解有误吗？作者回复: 请注意T1读取但并未修改ID=1的数据，只加了短暂的读锁，并没有加写锁，所以T2更新操作可以马上成功，不会被阻塞。如果T1对ID=1的数据修改过，T2是会被阻塞的。
2021-01-0534
而立斋【读已提交对事务涉及到的数据加的写锁，会一直持续到事务结束，但加的读锁在查询操作完成后就马上会释放】谁方便能给我解释一下这句话？我的理解 是这样的，一般写包含了一个查询的过程，所以在这个级别下，是先对需要修改的数据加写锁，在这个过程中涉及到查询的部分会加一个读锁，查询 完了这个读锁就释放了。写锁一直等到事务结束了才释放。 这里有一个点想不通，读锁也就是共享锁，你就释放了，只要写锁没有释放的话，其他事务再来申请读锁的话也会失败吧。也就是说所谓的不可重复读问题的出现应该是在写锁释放之后才发生的。作者回复: 文中有提到： 幻读、不可重复读、脏读等问题都是由于一个事务在读数据过程中，受另外一个写数据的事务影响而破坏了隔离性，针对这种“一个事务读+另一个事务写”的隔离问题。 对于RC的中举得例子是这样的： SELECT * FROM books WHERE id = 1; /* 时间顺序：1，事务： T1 */ UPDATE books SET price = 110 WHERE id = 1; COMMIT; /* 时间顺序：2，事务： T2 */ SELECT * FROM books WHERE id = 1; COMMIT; /* 时间顺序：3，事务： T1 */ 其中T2的UPDATE并不会被阻塞，因为T1是读事务，而且隔离级别是RC，在SELECT结束之后读锁就释放了，所以T2能成功提交。 如果把例子改成这样（但这种就不叫做Non-Repeatable Reads问题了）： SELECT * FROM books WHERE id = 1 FOR UPDATE; /* 时间顺序：1，事务： T1 */ UPDATE books SET price = 110 WHERE id = 1; COMMIT; /* 时间顺序：2，事务： T2 */ SELECT * FROM books WHERE id = 1; COMMIT; /* 时间顺序：3，事务： T1 */ 这样T2的UPDATE操作就是会被阻塞的，因为上面已经有了写锁。
2021-05-1722
雪糕周老师，好像发现了一个问题， 在可重复读的隔离级别下， 在一个事务里，读到的数量，都是一样的， SELECT * FROM books WHERE id = 1; /* 时间顺序：1，事务： T1 *//* 注意没有COMMIT */UPDATE books SET price = 90 WHERE ID = 1; /* 时间顺序：2，事务： T2 *//* 这条SELECT模拟购书的操作的逻辑 */SELECT * FROM books WHERE id = 1; /* 时间顺序：3，事务： T1 */ROLLBACK;作者回复: 原文： 这里我要提醒你注意一个地方，我这里的介绍实际上是以 ARIES 理论作为讨论目标的，而具体的数据库并不一定要完全遵照着这个理论去实现。我给你举个例子。MySQL/InnoDB 的默认隔离级别是可重复读，但它在只读事务中就可以完全避免幻读问题。
2021-05-192
大头越来越简洁的开发，大部分普通开发人员不需要了解的特别底层。熟悉业务逻辑，就能翻译为代码。但要想出色，要想知其然，知其所以然，还是需要了解底层的知识。如同金字塔，底下的人多，也容易到达。越往上越难，但替代成本也越高作者回复: 同意
2020-12-15
书生深入浅出！隔离级别的本质在于锁的运用，分别是 读锁+写锁+范围锁 读锁+写锁 写锁+读完就释放的读锁 只有写锁 MVCC解决的是读+写的问题，所以第一个和第四个锁的组合不用考虑这个问题2020-12-1470