知识点 | 再谈数据库事务的四种隔离级别

关于隔离性，之前写过几篇文章，链接如下：

专题_今天来聊一聊数据库事务的四种隔离性_Oracle和MySQL各自的默认隔离级别及原因分析

大家都知道，对数据的并发访问特性，是数据库的一大特性/买点。

但并发访问统一数据资源时，会带来一些问题，如下：

并发访问数据时可能遇到的问题：
1）脏读：B事务读取到了A事务尚未提交的数据；

2）不可重复读：B事务读到了A事务已经提交的数据，即B事务在A事务提交之前和提交之后读取到的数据内容
不一致（AB事务操作的是同一条数据）；

3）幻读/虚读：B事务读到了A事务已经提交的数据，即A事务执行插入操作，B事务在A事务前后读到的数据数量
不一致。

为了解决上述问题，数据库提供了事务的四种隔离机制。

1. read uncommitted（读未提交）: 一个事务还没提交时，它做的变更就能被别的事务看到，读取尚未提交的数据，哪个问题都不能解决；
2. read committed（读已提交）：一个事务提交之后，它做的变更才会被其他事务看到，读取已经提交的数据，可以解决脏读，RC为oracle默认的隔离机制；
3. repeatable read（可重复读）：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的，可以解决脏读和不可重复读，RR为mysql默认的隔离机制；
4. serializable（串行化）：顾名思义是对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。可以解决脏读、不可重复读和虚读，相当于锁表（flush tables with read lock;）。

注意：

1. 上述的隔离机制逐层递增，隔离性越大并发度越小，业务前端的反应就是支持的并发连接减少，且会出现超时等待的情况；好处是数据一致性得到更强保障。
2. serializable级别可以解决所有的数据库并发问题，但是它会在读取的每一行数据上都加锁，这就可能导致大量的超时和锁竞争问题，从而导致效率下降。所以在实际应用中也很少使用serializable，只有在非常需要确保数据的一致性而且可以接受没有并发的情况下，才考虑采用该级别。

文章至此。

以下为个人公众号，欢迎扫码关注：