03 事务隔离
03 事务隔离
事务：保证一组数据库操作，要么全部成功，要么全部失败。在 MySQL 中，事务支持是在引擎层实现的。
事务ACID（Atomicity、Consistency、Isolation、Durability，即原子性、一致性、隔离性、持久性）。
建议你尽量不要使用长事务。****
读未提交（read uncommitted）、读提交（read committed）、可重复读（repeatable read）和串行化（serializable ）
值得注意的是，隔离得越严实，效率就会越低。
读未提交：一个事务还没提交时，它做的变更就能被别的事务看到。
读提交：一个事务提交之后，它做的变更才会被其他事务看到。
可重复读：一个事务执行过程中看到的数据，总是跟这个事务在启动时看到的数据是一致的，未提交变更对其他事务也是不可见的。
串行化：对于同一行记录，“写”会加“写锁”，“读”会加“读锁”。当出现读写锁冲突的时候，后访问的事务必须等前一个事务执行完成，才能继续执行。
- 若隔离级别是“读未提交”， V1 是 2。这时候事务 B 虽然还没有提交，但是结果已经被 A 看到了。因此，V2、V3 也都是 2。
- 若隔离级别是“读提交”，V1 是 1，V2 是 2。事务 B 的更新在提交后才能被 A 看到。所以， V3是 2。
- 若隔离级别是“可重复读”，则 V1、V2 是 1，V3 是 2。V2 还是 1，事务在执行期间看到的数据前后必须是一致的。
- 若隔离级别是“串行化”， V1、V2 值是 1，V3 的值是 2。事务A一开始查询值1的时候就获得了读锁，根据两阶段加锁，事务A获得的锁要在commit的时候才释放，所以事务B在修改1为2的时候申请写锁会阻塞直到事务A提交，事务A提交之前获取的值都是1，所以V1 V2都是1，事务A提交后事务B获取到写锁完成更新操作，所以V3是2。
长事务：意味着系统里面会存在很老的事务视图。由于这些事务随时可能访问数据库里面的任何数据，所以这个事务提交之前，数据库里面它可能用到的回滚记录都必须保留，这就会导致大量占用存储空间。
MySQL 的事务启动方式：
- 显式启动事务语句：begin 或 start transaction。配套的提交语句是 commit，回滚语句是 rollback。
- set autocommit=0，这个命令会将这个线程的自动提交关掉。意味着如果你只执行一个 select 语句，这个事务就启动了，而且并不会自动提交。这个事务持续存在直到你主动执行 commit 或 rollback 语句，或者断开连接。
建议你总是使用 set autocommit=1, 通过显式语句的方式来启动事务。
问：如何避免长事务对业务的影响？
答：
从应用开发端来看：
- 确认是否使用了 set autocommit=0。
- 确认是否有不必要的只读事务。
- 业务连接数据库的时候，通过 SET MAX_EXECUTION_TIME 命令，控制每个语句执行的最长时间，避免单个语句意外执行太长时间。
从数据库端来看：
- 监控 information_schema.Innodb_trx 表，设置长事务阈值，超过就报警 / 或者 kill；
- Percona 的 pt-kill 工具不错；
- 在业务功能测试阶段要求输出所有的 general_log，分析日志行为提前发现问题；
- MySQL 5.6 或者更新版本，把 innodb_undo_tablespaces 设置成 2（或更大的值）。如果真的出现大事务导致回滚段过大，这样设置后清理起来更方便。