事务四大特性ACID
<b>原子性<br>Atomicity</b>
要么都成功，要么都失败，一个事务内的所有sql语句要保持同步的进行
实现原理：依靠undo.log日志，记录事务执行的sql，在事务失败时进行反向补偿，回滚数据
<b>一致性<br>Consistency</b>
事务前后总量不变，数据库的完整性约束没有被破坏
实现原理
从数据库层面，数据库通过原子性、隔离性、持久性来保证一致性
从应用层面，通过代码判断数据库数据是否有效，然后决定回滚还是提交数据
<b>隔离性<br>Isolation</b>
一个事务的执行不被其他事务干扰
<b>持久性<br>Durability</b>
事务一旦提交，结果便是永久性的
实现原理
主要依靠redo.log日志实现，在执行修改操作时，sql会先写入到redo.log日志，<br>再写入缓存，最后更新数据库，这样即使断电，也能保证数据库不丢失数据
Innodb_flush_log_at_trx_commit<br>
扩展
如果在commit前将内存中的数据写入到磁盘会有什么问题？
采用redo log的好处？
并发事务带来的问题
脏写/丢失更新
A事务提交或者撤销时，把B事务更新的数据给覆盖了
解决方案
悲观锁
select xx for update;
严重影响并发，不推荐
乐观锁
获取数据时不加锁，update时再去检查冲突
可使用版本号或者时间戳来判断是否修改过
读一致性
<b>脏读</b>：读到其他事务未提交的数据
<b>不可重复读</b>：读到其他事务已经提交的数据，导致两次查询的结果不同
<b>幻读</b>：读到其他事务已提交的数据行
不可重复读和幻读的区别？
前者读的是其他事务修改或删除的数据<br>而幻读读到的是其它事务新插入的数据
隔离级别
<b>读未提交</b> <b>READ UNCOMMITTED</b>：解决了脏写，会出现脏读
<b>读已提交</b> <b>READ COMMITTED</b>：解决了脏读，但会出现不可重复读
<b>可重复读 REPEATABLE READ</b>：解决了不可重复读，但会出现幻读（<b>InnoDB不会，默认隔离级别</b>）
<b>串行化 SERIALIZABLE</b>：使用表锁，降低并发性能
