MySQL-事务相关知识

事务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语句可以自动提交，防止出现长事务。
如何规避长事务
1. 针对业务开发人员，系统培训长事务相关知识
2. code review中，检查代码以及数据库相关配置信息
3. 测试人员，建立相关测试用例
4. 运维建立长事务监控脚本
长事务出现后的运维：长事务识别、处理，监控

生产项目分析

项目简介

目前的项目，使用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方法，事务就一定会生效

具体可以参考这篇博客：

嵌套事务总结