关于golang:数据库事务隔离级别

数据库的事务对数据并行拜访的时候，有可能会呈现一些问题，因而数据库设置了四个不同的隔离级别来解决问题。

在 MySQL 数据库的隔离级别能够分为四层，别离是读未提交、读提交、可反复读和串行化。与之对应呈现的问题有脏读、幻读、不可反复读。

<!–more–>

隔离级别

读未提交 (read uncommited)

一个事务还未提交时，它做的变更就能被其余的事务看到。

读提交 (read commited)

一个事务提交之后，它做的变更才会被其余事务看到

可反复读 (repeatable read)

一个事务执行过程中看到的数据，总是跟这个事务启动时看到的数据是统一的。在此隔离级别下，未提交的事务对其余事务也是不可见的。

串行化 (serializable)

对同一行记录，“写”会加“写锁”，“读”会加“读锁”。当呈现读写锁抵触的时候，后拜访的事务必须等前一个事务执行实现，能力继续执行。
此隔离级别保障了数据的正确性，然而频繁的加锁会对性能造成重大的影响。

不同的事务隔离级别对应的问题

脏读

在“读未提交”级别下，未提交的变更被其余事务看到了，对其余事务来说，这些未提交的变更就是脏数据，这样的景象就称之为“脏读”。

不可反复读

在“读提交”级别下，只有事务提交之后，别的事务能力看到事务做的更改，然而当一个事务 A 在执行过程中屡次查问某个值，第一次查问的时候值为 v1, 而后在事务 B 把值批改了，当事务 A 再次查问的时候，就会发现这个值不一样了，明明是同一个事务进行的查问操作，两次查问进去的后果却不同，这就是“不可反复读”

幻读

“幻读”与“不可反复读”比拟相似，事务 A 查问某个值，如果不存在，就插入，当事务 A 查问到不存在之后，事务 B 插入了这个值，事务 A 再去插入的时候就会发现之前查问不存在的值竟然有了。解决幻读的办法就是设置事务隔离级别为“串行化”，即无论读写，都对数据加锁。

用上面这个过程来展现一下区别

• 若隔离级别是“读未提交”, 则 v1 的值就是 2. 这时候事务 B 尽管还没有提交，然而后果曾经被 A 看到了。因而，v2、v3 都是 2。
• 若隔离级别是“读提交”，则 v1 是 1，v2 的值是 2. 事务 B 的更新在提交后能力被 A 看到。所以，v3 的值也是 2.
• 若隔离级别是“可反复读”，则 v1、v2 是 1，v3 是 2。在“可反复读”级别下须要遵循这个要求：事务在执行期间看到的数据前后必须都是始终的。
• 若隔离级别是“串行化”, 则在事务 B 执行“将 1 改为 2”的时候，会被锁住。晓得事务 A 提交之后，事务 B 才能够继续执行。所以从 A 的角度看，v1、v2 的值是 1,v3 的值是 2.

在事务的隔离级别实现上，数据库外面会创立一个视图，拜访的时候以视图的逻辑后果为准。

• 在“可反复读”隔离级别下，这个视图是在事务启动时创立的，整个事务执行期间都应用这个视图；
• 在“读提交”级别下，这个视图是在每个 SQL 语句开始执行的时候创立的；
• 如果是“读未提交”级别，间接返回记录上的最新值，没有视图概念；而在“串行化”级别下间接用加锁的形式来防止并行拜访。

公众号：没有幻想的阿巧 后盾回复 “ 群聊 ”，一起学习，一起提高