5 多版本并发控制（MVCC）

使InnoDB支持一致性读：

• READ COMMITTED
• REPEATABLE READ、

让查询不被阻塞、无需等待被其他事务持有的锁，可以增加并发度。

InnoDB保留被修改行的旧版本。查询正在被其他事务更新的数据时，会读取更新之前的版本。每行数据都存在一个版本号，每次更新时都更新该版本。

聚簇索引的更新=替换更新

二级索引的更新=删除+新建

6 事务启动方式

6.1 显式启动事务、

begin 或 start transaction 开启事务：

• 提交语句 commit
• 回滚语句 rollback

6.2 set autocommit=1

set autocommit=0 

将该线程的自动提交关闭。如果你只执行一个select，事务就启动了，且不会自动提交。

该事务会持续存在，直到主动执行commit 或 rollback，或断开连接。

有些客户端连接框架会默认连接成功后先执行

set autocommit=0

导致接下来的查询都在事务中，若是长连接，就导致意外的长事务。

因此建议总用

set autocommit=1

显式启动事务。

频繁事务的业务，第二种方式每个事务在开始时都不需要主动执行一次 “begin”，减少了语句交互次数。如果你也有这个顾虑，建议使用commit work and chain。

autocommit为1时，用begin显式启动的事务，若执行commit，则提交事务。

若执行 commit work and chain，则是提交事务并自动启动下个事务，省去执行begin语句的开销。从程序开发的角度也能明确知道每个语句是否处于事务。

7 查询长事务

information_schema库的innodb_trx表中查询长事务

• 查找持续时间超过60s的事务。

select * from information_schema.innodb_trx where
TIME_TO_SEC(timediff(now(),trx_started))>60

8 日备 V.S 周备

好处是“最长恢复时间”更短。

• 一天一备
  最坏情况下需要应用一天的binlog。比如，你每天0点做一次全量备份，而要恢复出一个到昨天晚上23点的备份

• 一周一备
  最坏情况就要应用一周的binlog啦！

系统的对应指标是RTO（恢复目标时间）。

当然这个是有成本的，因为更频繁全量备份需要消耗更多存储空间，所以这个RTO是成本换来的，需要根据业务评估。

9 避免长事务对业务的影响

长事务意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问db里的任何数据，所以该事务提交之前，db里它可能用到的回滚记录都必须保留，导致大量占存储。

在MySQL 5.5及以前，undo log是跟数据字典一起放在ibdata文件，即使长事务最终提交，回滚段被清理，文件也不会变小。

除了对回滚段影响，长事务还占用锁资源，可能拖慢全库。

9.1 应用开发端

确认是否使用

set autocommit=0

确认可在测试环境中，把MySQL的general_log开启，随便跑个业务逻辑，通过general_log确认。

一般框架如果设置该值，也会提供参数来控制，目标就是把它改成1。

确认是否有不必要的只读事务。有些框架不管什么语句先begin/commit框。有些是业务并没有这需要，但也把好几个select语句放到事务。这种只读事务可以去掉。

业务连接数据库时，根据业务预估，通过SET MAX_EXECUTION_TIME命令，控制每个语句执行最长时间，避免单语句意外执行太长时间。

9.2 数据库端

监控 information_schema.Innodb_trx表，设置长事务阈值，超过就报警/或者kill。

Percona的pt-kill这个工具不错，推荐。

在业务功能测试阶段要求输出所有的general_log，分析日志行为提前发现问题。

使用的MySQL 5.6或更新版本，把innodb_undo_tablespaces设置成2或更大值。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。