持续创作,加速成长!这是我参与「掘金日新计划 · 6 月更文挑战」的第5天,点击查看活动详情
前言
大家好,我是小郭,在实际的功能中,我们为了解决数据安全操作的问题,事务用大白话来说,就是要么全部成功,要么全部失败,对于隔离级别对应的业务场景,我们又有多少的了解呢,接下来开始我们的学习。
事务的隔离级别
- 读未提交是指,一个事务还没提交时,它做的变更就能被别的事务看到,会避免脏读。
- 读已提交是指,一个事务提交之后,它做的变更才会被其他事务看到,会避免脏读和脏写。
- 可重复读是指,一个事务执行过程中看到的数据,总是跟这个事务在启动时看到的数据是一致的,会避免脏读、脏写和不可重复读。
- 串行化,顾名思义是对于同一行记录,“写”会加“写锁”,“读”会加“读锁”。当出现读写锁冲突的时候,后访问的事务必须等前一个事务执行完成,才能继续执行。
读已提交和可重复读的区别
可重复读是在读事务前已提交,读已提交是指读已提交。
基本要素ACID
- 原子性(Atomicity) 事务开始后所有操作,要么全做,要么不做
- 一致性(Consistency) 事务开始前和后,数据库的完整性约束没有被破坏
- 隔离性(Lsolation) 同一时间,只允许一个事务请求同一数据,不同的事务之间彼此没有任何干扰
- 持久性(Durability) 事务完成后,事务对数据库的所有所有更新将被保存到数据库,不能回滚
事务的启动方式?
- 显式启动事务语句, begin 或 start transaction。配套的提交语句是 commit,回滚语句是 rollback。
- set autocommit=0,这个命令会将这个线程的自动提交关掉。 如果线程没有进行事务提交,可能同时一直占用写的资源,拖垮整个库,这就是我们所说的长事务。
MySQL是怎么完成事务?
事务的隔离性:
InnoDB 在实现 MVCC 时用到的一致性读视图,即 consistent read view,用于支持 RC(Read Committed,读提交)和 RR(Repeatable Read,可重复读)隔离级别的实现
一张图,来认识一下MVCC
事务的原子性:
事务的持久性:
长事务的危害
什么是长事务?对的,占着茅坑不拉屎的就叫长事务
为什么要避免长事务?
如何避免长事务?
总结
从这篇文章中,我们主要回顾了隔离级别,以及隔离的启动方式,知道了事务的原子性是由Undo Log来实现的,事务的持久性是由Redo Log来实现的,事务的隔离性是由读写锁和MVCC来实现的,到最后的在实际中如何取规避长事务。