数据库隔离级别实现原理[通俗易懂]

大家好，又见面了，我是你们的朋友全栈君。

昨晚和以为前辈聊天，聊到Mysql的引擎innodb默认的事务隔离级别是REPEATABLE READ（可重复读）；在Oracle中默认的事务隔离级别是提交读（read committed）。那么，问题来了，在Mysql中的隔离级别是怎么实现的呢？ 关于数据库数据隔离级别在之前的博客中总结过：https://blog.csdn.net/qq_34417408/article/details/79935859；下面主要说说原理： READ_UNCOMMITED 的原理:

事务对当前被读取的数据不加锁； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级共享锁，直到事务结束才释放。 表现：

事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，能读到事务2对该记录的修改版本，即使该修改尚未被提交。 事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。 READ_COMMITED 的原理:

事务对当前被读取的数据加 行级共享锁（当读到时才加锁），一旦读完该行，立即释放该行级共享锁； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。 表现：

事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的只能是事务2对其更新前的版本，要不就是事务2提交后的版本。 事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。 REPEATABLE READ 的原理:

事务在读取某数据的瞬间（就是开始读取的瞬间），必须先对其加 行级共享锁，直到事务结束才释放； 事务在更新某数据的瞬间（就是发生更新的瞬间），必须先对其加 行级排他锁，直到事务结束才释放。 表现：

事务1读取某行记录时，事务2也能对这行记录进行读取、更新；当事务2对该记录进行更新时，事务1再次读取该记录，读到的仍然是第一次读取的那个版本。 事务1更新某行记录时，事务2不能对这行记录做更新，直到事务1结束。 SERIALIZABLE 的原理:

事务在读取数据时，必须先对其加 表级共享锁 ，直到事务结束才释放； 事务在更新数据时，必须先对其加 表级排他锁 ，直到事务结束才释放。 表现：

事务1正在读取A表中的记录时，则事务2也能读取A表，但不能对A表做更新、新增、删除，直到事务1结束。 事务1正在更新A表中的记录时，则事务2不能读取A表的任意记录，更不可能对A表做更新、新增、删除，直到事务1结束。

这里涉及到排他锁和共享锁，解释一波：

共享锁【S锁】 又称读锁，若事务T对数据对象A加上S锁，则事务T可以读A但不能修改A，其他事务只能再对A加S锁，而不能加X锁，直到T释放A上的S锁。这保证了其他事务可以读A，但在T释放A上的S锁之前不能对A做任何修改。

排他锁【X锁】 又称写锁。若事务T对数据对象A加上X锁，事务T可以读A也可以修改A，其他事务不能再对A加任何锁，直到T释放A上的锁。这保证了其他事务在T释放A上的锁之前不能再读取和修改A。

这个和之前的数据库隔离级别博客一起看比较易懂。同时也自省一下，在技术的道路上，永远做个小白，勇于探索底层，向届内前辈看齐！同时，多沟通，多实践，多总结，多积累，勇于发现自己的短板。共勉！

发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/141536.html原文链接：https://javaforall.cn