[＜事务专题＞]
事务专题
- [1] 事务的四种特性？
- [2] 并发操作会产生的问题
- [3]事务的隔离级别有哪些？
[1] 事务的四种特性？
- 原子性（Atomicity）：事务作为一个整体被执行 ，要么全部执行，要么全部不执行
- 一致性（Consistency）：保证数据库状态从一个一致状态转变为另一个一致状态
- 隔离性（Isolation）：多个事务并发执行时，一个事务的执行不应影响其他事务的执行
- 持久性（Durability）：一个事务一旦提交，对数据库的修改应该永久保存
事务是数据库的概念**：园艺搁池**
[2] 并发操作会产生的问题
link
假如有事务1，事务2两个事务.
- 第一类丢失更新：由于事务1的回滚，导致事务2更新的的数据丢失.
- 第二类丢失更新：由于事务1的提交，导致事务2更新的的数据丢失.
- 脏读：事务2读取了事务1未提交的数据，由于事务1回滚，导致的数据不一致.
- 不可重复读：事务1前后多次读取，由于事务2期间修改了数据，导致数据内容不一致.
- 幻读：事务1读的时候读出了N条记录，事务2在事务1执行的过程中增加 了1条，事务1再读的时候就变成了N+1条.
更脏不换
不可重复复和幻读的区别在于前者是对于单行，后者是对于多行而言，因此前者主要是针对更新操作，后者是针对于插入操作
[3]事务的隔离级别有哪些？
Mysql如果不加限制，会造成一系列的并发问题，所以需要进行加锁操作.但是加锁会影响性能，所以存在矛盾，事务的隔离划分出不同的隔离级别就是为了在不同场景内选择适合的隔离级别.事务的隔离级别越高，对数据的完整性和一致性保证越佳，但是对并发操作的影响也越大.MySQL事务默认隔离级别是可重复读.
数据库的事务隔离越严格，并发副作用越小，但付出的代价也就越大，因为事务隔离实质上就是使事务在一定程度上 “串行化”进行，这显然与“并发”是矛盾的。同时，不同的应用对读一致性和事务隔离程度的要求也是不同的，比如许多应用对“不可重复读”和“幻读”并不敏 感，可能更关心数据并发访问的能力。
为了解决“隔离”与“并发”的矛盾，ISO/ANSI SQL92定义了4个事务隔离级别，每个级别的隔离程度不同，允许出现的副作用也不同，应用可以根据自己的业务逻辑要求，通过选择不同的隔离级别来平衡 “隔离”与“并发”的矛盾。下表很好地概括了这4个隔离级别的特性。
原文链接：https://blog.csdn.net/soonfly/article/details/70238902
所有写操作都会加排它锁， 排他锁会阻止其它事务再对其锁定的数据加读或写的锁，但是对不加锁的读(select)就不起作用了。
READ UNCOMMITTED(读未提交) ： 对于修改的项加排它锁，直到事务结束释放；没有快照读，只能读最新版本的数据，不能避免任何并发问题。
READ COMMITTED(读已提交) ：对于修改的项加排它锁，直到事务结束释放；有快照读，快照的粒度是语句级。可以避免更新丢失和脏读。
REPEATABLE READ(可重复度) ：对于修改的项加排它锁，直到事务结束释放；有快照读，快照的粒度是事务级。可以避免不可重复读。
SERIALIZABLE（串行化） ：对于修改的项加排它锁， 使用间隙锁解决幻读问题，不会引发并发问题。
可重复读：https://blog.csdn.net/wangbaosongmsn/article/details/106874093
InnoDB在每行记录后面保存两个隐藏的列来，分别保存了这个行的创建时间和行的删除时间.这里存储的并不是实际的时间值，而是系统版本号，当数据被修改时，版本号加1
在读取事务开始时，系统会给当前读事务一个版本号，事务会读取版本号<=当前版本号的数据
此时如果其他写事务修改了这条数据，那么这条数据的版本号就会加1，从而比当前读事务的版本号高，读事务自然而然的就读不到更新后的数据了./MVCC会让修改操作（读取，删除）增加一个版本号，可重复读让读事务指定同样的版本号，不会读到另外事务修改的版本号./