mysql> show variables like 'transaction_isolation'; 这句写错了，应该是tx_isolation。测试了一下

1、务的特性：原子性、一致性、隔离性、持久性 2、多事务同时执行的时候，可能会出现的问题：脏读、不可重复读、幻读 3、事务隔离级别：读未提交、读提交、可重复读、串行化 4、不同事务隔离级别的区别： 读未提交：一个事务还未提交，它所做的变更就可以被别的事务看到 读提交：一个事务提交之后，它所做的变更才可以被别的事务看到 可重复读：一个事务执行过程中看到的数据是一致的。未提交的更改对其他事务是不可见的 串行化：对应一个记录会加读写锁，出现冲突的时候，后访问的事务必须等前一个事务执行完成才能继续执行 5、配置方法：启动参数transaction-isolation 6、事务隔离的实现：每条记录在更新的时候都会同时记录一条回滚操作。同一条记录在系统中可以存在多个版本，这就是数据库的多版本并发控制（MVCC）。 7、回滚日志什么时候删除？系统会判断当没有事务需要用到这些回滚日志的时候，回滚日志会被删除。 8、什么时候不需要了？当系统里么有比这个回滚日志更早的read-view的时候。 9、为什么尽量不要使用长事务。长事务意味着系统里面会存在很老的事务视图，在这个事务提交之前，回滚记录都要保留，这会导致大量占用存储空间。除此之外，长事务还占用锁资源，可能会拖垮库。 10、事务启动方式：一、显式启动事务语句，begin或者start transaction,提交commit，回滚rollback；二、set autocommit=0，该命令会把这个线程的自动提交关掉。这样只要执行一个select语句，事务就启动，并不会自动提交，直到主动执行commit或rollback或断开连接。 11、建议使用方法一，如果考虑多一次交互问题，可以使用commit work and chain语法。在autocommit=1的情况下用begin显式启动事务，如果执行commit则提交事务。如果执行commit work and chain则提交事务并自动启动下一个事务。 思考题： 在开发过程中，尽可能的减小事务范围，少用长事务，如果无法避免，保证逻辑日志空间足够用，并且支持动态日志空间增长。监控Innodb_trx表，发现长事务报警。 疑问： 关于第二节的思考题，读题干的意思，是在什么场景下，一天一备比一周一备更有优势。老师的答案只是给出了一天一备的优势，那么适用场景怎么理解呢？

预告：林晓斌老师将做客极客Live，分享他MySQL的心路历程 前阿里丁奇：我的MySQL心路历程 11月21日（周三） 20:30-21:30 本次直播，林晓斌将畅谈个人成长经历，分享自己是如何从数据库小白逐步成长为MySQL内核开发人员的。从业十几年，他经历了哪些比较重要的事儿？他觉得什么事儿最有难度？什么事儿最有成就感？他是怎样应对的？ 1、MySQL数据库的最佳学习路径 2、丁奇遇到过哪些挑战？走过那些坑？是如何应对的？ 3、从业十几年来，关于数据库性能的“奇闻异事” 加小助手微信：geektime001或geektime004（二选一），获取直播最新消息

读未提交：别人改数据的事务尚未提交，我在我的事务中也能读到。 读已提交：别人改数据的事务已经提交，我在我的事务中才能读到。 可重复读：别人改数据的事务已经提交，我在我的事务中也不去读。 串行：我的事务尚未提交，别人就别想改数据。 这4种隔离级别，并行性能依次降低，安全性依次提高。

为该讲总结了几个问题, 大家复习的时候可以先尝试回答这些问题检查自己的掌握程度: 1. 事务的概念是什么? 2. mysql的事务隔离级别读未提交, 读已提交, 可重复读, 串行各是什么意思? 3. 读已提交, 可重复读是怎么通过视图构建实现的? 4. 可重复读的使用场景举例? 对账的时候应该很有用? 5. 事务隔离是怎么通过read-view(读视图)实现的? 6. 并发版本控制(MCVV)的概念是什么, 是怎么实现的? 7. 使用长事务的弊病? 为什么使用常事务可能拖垮整个库? 8. 事务的启动方式有哪几种? 9. commit work and chain的语法是做什么用的? 10. 怎么查询各个表中的长事务? 11. 如何避免长事务的出现?

下面是我的自问自答，也是我的学习笔记，问下斌哥，这样理解准确吗？ 在可重复读的隔离级别下，如何理解**当系统里没有比这个回滚日志更早的 read-view 的时候**，这个回滚日志就会被删除？ 这也是**尽量不要使用长事务**的主要原因。 比如，在某个时刻（今天上午9:00）开启了一个事务A（对于可重复读隔离级别，此时一个视图read-view A也创建了），这是一个很长的事务…… 事务A在今天上午9:20的时候，查询了一个记录R1的一个字段f1的值为1…… 今天上午9:25的时候，一个事务B（随之而来的read-view B）也被开启了，它更新了R1.f1的值为2（同时也创建了一个由2到1的回滚日志），这是一个短事务，事务随后就被commit了。 今天上午9:30的时候，一个事务C（随之而来的read-view C）也被开启了，它更新了R1.f1的值为3（同时也创建了一个由3到2的回滚日志），这是一个短事务，事务随后就被commit了。 …… 到了下午3:00了，长事务A还没有commit，为了保证事务在执行期间看到的数据在前后必须是一致的，那些老的事务视图、回滚日志就必须存在了，这就占用了大量的存储空间。 源于此，我们应该尽量不要使用长事务。

事务隔离的实现似乎有点太简略，没跟上林老师的思路。。

在“可重复读”隔离级别下，这个视图是在事务启动时创建的，整个事务存在期间都用这个视图。 这种说法似乎不准确：这个视图应该是“在事务内第一次查询时被创建，整个事务存在期间都用这个视图“。 例如 RR级别下，有记录 id 1, name zhang tx1 begin tx 2 begin tx2 update T set name = 'li' where id = 1; tx2 commt; tx1 select 结果是li

帮助记忆： 视图理解为数据副本，每次创建视图时，将当前『已持久化的数据』创建副本，后续直接从副本读取，从而达到数据隔离效果。 存在视图的 2 种隔离级别： 1. 读提交 2. 可重复读 读提交：在每一条 SQL 开始执行时创建视图，隔离作用域仅限该条 SQL 语句。 可重复读：事务启动时创建视图，因此，在事务任意时刻，对记录读取的值都是一样的。 其他 2 种无视图的隔离级别： 1. 读未提交 2. 串行化 读未提交：直接返回记录最新值。 串行化：通过读写锁来避免并行访问。 读-读：允许并发执行 读-写：只能串行 写-写：只能串行 老师，关于视图理解为数据副本，“读-读”在串行化隔离级别允许并发，这样的理解是否适合呢？谢谢

老师，MySQL中undo的内容会被记录到redo中吗？比如一个事务在执行到一半的时候实例崩溃了，在恢复的时候是不是先恢复redo，再根据redo构造undo回滚宕机前没有提交的事务呢？