持续创作，加速成长！这是我参与「掘金日新计划 · 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来实现的，到最后的在实际中如何取规避长事务。
