事务ACID的理解
引入事务的主要目的：
- 保证数据库从一个一致性状态切换为另一种一致性状态
- 所有修改要么都保存，要么都不保存
A 原子性
原子性关注单个事务的整体性，需要保证事务中的全部操作是一个单元，要么都成功，要么都失败。
C 一致性
一致性关注，事务开始和结束后，数据库的完整性约束没有被破坏。简单理解，如果有外键的存在，事务执行前，外键可以保证一致性约束；事务执行之后，这个一致性约束也不应该被破坏。
I 隔离性
隔离性关注多个事务之间是否彼此互相不知晓，不影响。
没有隔离性带来的问题
没有隔离级别的时候，多个事务互相交替执行，会出现一些问题：
- 脏读：读取到其他事务未提交的数据
- 不可重复读：在事务的开始和结束这段时间，对同一行数据，读取到的值是不同的
- 幻读：事务开始和结束这段时间，同一个查询，查询到的数据行数不一致
四种隔离级别
四种隔离级别，可以分别解决不同的隔离性问题：
- 读未提交：事务可以读到其他事务未提交的数据
- 有脏读，不可重复读，幻读问题
- 读已提交：事务可以读到其他事务已经提交的数据
- 解决脏读问题，仍有不可重复读，幻读问题
- 可重复读：事务在开始到结束这段时间，读到的同一行数据是一致的。
- 解决脏读、不可重复读，仍有幻读问题
- 串行化：事务和事务之间是串行执行的
- 所有问题都可以解决
这四种隔离级别的隔离读，从上到下越来越高，但是性能从上到下越来越低。
隔离性的实现
实现上，数据库会创建一个视图，访问的时候以这个视图的逻辑结果为准。
- 读未提交：不创建视图
- 读已提交：在事务中的每条sql语句执行前创建视图
- 可重复读：事务开始时创建，整个事务执行过程中都已这个视图为准
- 串行化：直接使用加锁的方式实现
在每一次更新操作以后，会记录一条回滚日志，当前的最新值，可以通过回滚日志回滚到之前的某一个状态，MVCC（多版本并发控制）就是通过回滚段实现的，同一条记录在系统中存在多个版本，不同时刻启动的事务，查看到的就是不同的版本值，并且版本之间互不干扰。
回滚日志是会被删除的，当系统判断，没有事务会用到这些回滚日志的时候就会删除回滚日志，也就是说当这个系统中没有比这个回滚日志更早的事务视图的时候。
可重复读的适用场景
可重复读，适用于对账场景，在对账过程中，其他事务对数据库的更改，不会影响校对结果。
最佳实践
- 基于回滚日志的描述，不建议使用长事务，长事务意味着系统中会存在很多很老的回滚日志，会占用大量存储空间
- 另外，长事务本身可能需要非常长的时间来执行，当事务中出现问题需要回滚时，回滚本身的时间也会很长
- 建议保持autocomit为1，用手动开启事务的方式来使用事务。
- begin来显示开启一个事务，mysql会自动执行set autocommit = 0；在commit或rollback后会set autocommit = 1；
- 如果autocommit为0，每次都需要手动设置commit或rollback，不需要事务的时候也需要提交
- autocommit为1，有些sql语句可以自动提交，防止出现长事务。
- 如何规避长事务
- 针对业务开发人员，系统培训长事务相关知识
- code review中，检查代码以及数据库相关配置信息
- 测试人员，建立相关测试用例
- 运维建立长事务监控脚本
- 长事务出现后的运维：长事务识别、处理，监控
生产项目分析
项目简介
目前的项目，使用springboot结合mybatis做数据库操作，事务管理使用Transactional注解实现，springboot默认使用的hikari pool连接池获取连接，该连接池autocommit属性值默认为true。在开启了事务的方法中，springboot会将连接的autocommit设置为false，代码如下：
类文件：org/springframework/jdbc/datasource/DataSourceTransactionManager.java
// switch to manual commit if necessary. this is very expensive in some jdbc drivers,
// so we don't want to do it unnecessarily (for example if we've explicitly
// configured the connection pool to set it already).
if (con.getautocommit()) {
txobject.setmustrestoreautocommit(true);
if (logger.isdebugenabled()) {
logger.debug("switching jdbc connection [" + con + "] to manual commit");
}
con.setautocommit(false);
}
在完成之后，如果autocommit为true，会自动恢复。
if (txObject.isMustRestoreAutoCommit()){
con.setAutoCommit(true);
}
事务失效问题
在生产实践中，很容易出现事务失效的问题，具体表现为调用事务方法，出异常后未回滚。编写代码时，按照下面的规范执行，就不会出现这个问题了。
A方法和B方法都有事务时，A方法调用B方法
- 如果A方法和B方法在同一个类中，需要通过容器调用B方法
- 如果A方法和B方法不在同一个类中，直接调用即可
A方法无事务，B方法有事务
- 只要A方法保证通过容器调用B方法，事务就一定会生效
具体可以参考这篇博客：
嵌套事务总结
