总结
-
事务的特性：ACID（Atomicity、Consistency、Isolation、Durability）即原子性、一致性、隔离性、持久性
-
多事务同时执行的时候，可能会出现的问题：脏读、不可重复读、幻读 。
脏读：读到其他事务未提交的数据；
不可重复读：前后读取的记录内容不一致；
幻读：前后读取的记录数量不一致。
-
事务隔离级别：读未提交、读提交、可重复读、串行化
-
不同事务隔离级别的区别：
-
读未提交：一个事务还未提交，它所做的变更就可以被别的事务看到
-
读已提交：一个事务提交之后，它所做的变更才可以被别的事务看到
-
可重复读：一个事务执行过程中看到的数据是一致的。未提交的更改对其他事务是不可见的
-
串行化：对应一个记录会加读写锁，出现冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行
这4种隔离级别，并行性能依次降低，安全性依次提高。
-
-
事务隔离级别的实现：
在实现上，数据库里面会创建一个视图，访问的时候以视图的逻辑结果为准。在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。在“读提交”隔离级别下，这个视图是在每个 SQL 语句开始执行的时候创建的。“读未提交”隔离级别下直接返回记录上的最新值，没有视图概念；而“串行化”隔离级别下直接用加锁的方式来避免并行访问。
-
事务隔离的实现：每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。不同时刻启动的事务会有不同的 read-view。
-
回滚日志什么时候删除？系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。
-
什么时候不需要了？当系统里没有比这个回滚日志更早的read-view的时候。
-
为什么尽量不要使用长事务。长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。
-
事务启动方式：
一、显式启动事务语句，begin或者start transaction，提交commit，回滚rollback；
二、set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个select语句，事务就启动，并不会自动提交，直到主动执行commit或rollback或断开连接。
-
建议使用方法一，如果考虑“多一次交互”问题，可以使用commit work and chain语法。在autocommit=1的情况下用begin显式启动事务，如果执行commit则提交事务。如果执行commit work and chain则提交事务并自动启动下一个事务。
思考题
系统里面应该避免长事务，如果你是业务开发负责人同时也是数据库负责人，你会有什么方案来避免出现或者处理这种情况呢？
首先，从应用开发端来看：
-
确认是否使用了 set autocommit=0。这个确认工作可以在测试环境中开展，把 MySQL 的 general_log 开起来，然后随便跑一个业务逻辑，通过 general_log 的日志来确认。一般框架如果会设置这个值，也就会提供参数来控制行为，你的目标就是把它改成 1。
-
确认是否有不必要的只读事务。有些框架会习惯不管什么语句先用 begin/commit 框起来。有些是业务并没有这个需要，但是也把好几个 select 语句放到了事务中。这种只读事务可以去掉。
-
业务连接数据库的时候，根据业务本身的预估，通过 SET MAX_EXECUTION_TIME 命令，来控制每个语句执行的最长时间，避免单个语句意外执行太长时间。
其次，从数据库端来看：
-
监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started)) > 60 查找持续时间超过 60s 的事务 -
Percona 的 pt-kill 这个工具不错，推荐使用；
-
在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
-
如果使用的是 MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。