课后问题：
在命令行先执行以下命令（注意不要提交事务）：
BEGIN;
UPDATE t SET a=2 WHERE id=1;

新建一个命令行终端，执行以下命令：
UPDATE t SET a=2 WHERE id=1;

从新建的命令行终端的执行结果看，这条更新语句被阻塞了，如果时间足够的话（InnoDB行锁默认等待时间是50秒），还会报锁等待超时的错误。
综上，MySQL应该是采用第3种方式处理题述场景。

对于MySQL为什么采用这种方式，我们可以利用《08 | 事务到底是隔离的还是不隔离的？》图5的更新逻辑图来解释：假设事务C更新后a的值就是2，而事务B执行再执行UPDATE t SET a=2 WHERE id=1;时不按第3种方式处理，即不加锁不更新，那么在事务B中接下来查询a的值将还是1，因为对事务B来说，trx_id为102版本的数据是不可见的，这就违反了“当前读的规则”。

以上是我的理解与分析，不是很确定准确与否。

看到自己的问题上榜，这是对自己的最大鼓励。

学习专栏之前，自己只是一个 CRUD boy，平时同事间讨论 MySQL 的问题，自己完全搭不上话，因为对 MySQL 底层原理完全不懂。对 MySQL 的认知就仅限一点：索引能提高查询效率。但是为什么能提高？不知道！！

现在回想，以前犯过很多错误：
1. 主键使用 UUID，非自增主键。
2. 滥用索引，其实可以通过“最左前缀原则”来精减索引。
3. 不管 SQL 语句是否合理，只要能返回结果集就是好 SQL。
4. 建表时字段类型拿捏不准。

现在都会反复学习专栏的每一篇文章，每次学习都有不一样的收获。
第一次可能是：喔，原来有这么个知识点，但对它的实现原理一知半解。
第二次却是：对它的实现原理有了更深的认识，加强对知识的理解，基本会形成一个比较清晰的逻辑。
第三次是，MySQL 的这种实现原理，是为了解决什么问题等等。

现在感觉有点“走火入魔”了，以前执行查询语句，关注的多久能返回结果集。
现在关注的却是：连接器、分析器、优化器、执行器和 InnoDB 引擎。
连接成功后，获取我的权限，查询缓存，命中缓存直接返回，否则进行后续的操作。（记得老师留言区回复过：连接器取权限，执行器用权限。而编写留言到这产生了一个疑问：查询缓存前，应该会校验权限，所以连接器也会用权限？）
分析器阶段进行词法分析，解析关键字，字段名，表名等。语法分析判断语法是否正确。（记得第一篇《基础架构》留言提到语义分析，今晚要找资料学习下）。
优化器阶段生成执行计划，选择索引（这时会怀疑 MySQL 选择的索引是否最优），能否使用索引下推和覆盖索引减少回表查询，提高性能。
执行器阶段调用引擎接口查询数据，Server 层要啥，引擎给啥，InnoDB 只给必要的值。
查询结束后，返回结果集，并将结果集放入查询缓存。

更新语句的关注点是隔离性，视图，MVCC，回滚日志，redo log，binlog，两阶段提交等。
写业务代码时，会考虑事务内的 SQL 语句，能否调整 SQL 语句的顺序，减少更新表时行锁对性能的影响。
在建表的时，会反复推敲这个索引是否合理。使用普通索引还是唯一索引更为合适。能否通过“最左前缀原则”来减少创建索引的个数。如果索引字段的类型是字符串并长度太长，如何优化使用前缀索引，减少空间占用，提高查询性能。

学习专栏后，基本上涉及到 MySQL 的内容，这些知识点都会浮现在脑海中。昨天还差点应用这些知识，帮同事优化他的 SQL 语句。昨天跟往常一样，当写代码写累了，就跑到同事那溜达溜达。
他正在线上的备库测试查询百万数据要多久，另一位同事建议他使用 force index 强制索引，这次执行 5 秒，再执行零点几秒。
他惊乎，为啥这次这么快。我说，这次查了缓存。我还想帮他看看 SQL 语句，是否 MySQL 选择错了索引，导致使用 force index 显式指定索引。说不定使用 order by field 就解决了呢，哈哈哈哈。后面有事，没有继续跟进他这问题了。

非常感恩，跟着老师学习，让我体会到了学习是一件自然而又充满魅力的事情，也让我从一个基础不牢固的小白，一步步地充实了自己的知识库，另外老师非常尽责，经常半夜回复答疑，希望老师保重身体。谢谢！！

关于刷脏页有两个问题请教老师:
1. 当redo log空间不足时, 按照redo log的顺序把脏页更新到磁盘, 那么假如一个脏页在第1条redo log中已经被持久化到磁盘, 后面第1000条redo log又有这个关于这个脏页的信息, 那么innoDB是直接丢弃掉这条redo log的记录吗? 还有这个时候, 是要把redo log上的全部内容更新到磁盘吗, 还是更新一部分?

2. 当内存不足开始刷脏页的时候, 以内存为刷脏页发起点, 这时是把最久不使用的数据页从内存中淘汰掉, 那么这个时候, 对应的额redo log是不是也会清除? 而对于该脏页的操作可能在redo log中并不是连续的记录, redo log有只能顺序读写, 那么redo log是怎么清除掉关于这个脏页的所有记录的?

创建测试数据：
mysql> create table t(id int primary key auto_increment,a int );
mysql> insert into t values(1,2);
mysql> begin;
Query OK, 0 rows affected (0.00 sec)
mysql> update t set a=2 where id=1;
Query OK, 0 rows affected (0.00 sec)
查看系统锁情况：
show engine innodb status
---TRANSACTION 958998, ACTIVE 51 sec
2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 2, OS thread handle 139663691581184, query id 22 localhost root
mysql> show processlist;
+----+------+-----------+--------------------+---------+------+----------+------------------+
| Id | User | Host | db | Command | Time | State | Info |
+----+------+-----------+--------------------+---------+------+----------+------------------+
| 2 | root | localhost | sysbench | Sleep | 352 | | NULL |
| 3 | root | localhost | NULL | Sleep | 301 | | NULL |
+----+------+-----------+--------------------+---------+------+----------+------------------+
其中Thread id=2 为update会话，说明系统有锁
另一会话执行 update t set a=2 where id=1;
ERROR 1205 (HY000): Unknown error 1205 MySQL error code 1205 (ER_LOCK_WAIT_TIMEOUT): Lock wait timeout exceeded; try restarting transaction
提交第一个会话查看生成的binlog
### INSERT INTO `sysbench`.`t`
### SET
### @1=1 /* INT meta=0 nullable=0 is_null=0 */
### @2=2 /* INT meta=0 nullable=1 is_null=0 */
# at 858
#181217 14:28:21 server id 9012 end_log_pos 889 CRC32 0xf96f7fcb     Xid = 20
COMMIT/*!*/;
# at 889
#181217 14:42:14 server id 9012 end_log_pos 930 CRC32 0x3de034ba     Rotate to bin.000089 pos: 4
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;
# End of log file
/*!50003 SET COMPLETION_TYPE=@OLD_COMPLETION_TYPE*/;
/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=0*/;
发现没有update的binlog产生，也就是说该语句在server层没有实际执行
用hexdump对比update前后的数据行，发现事务id和回滚id也没变，说明innodb没有实际更新行。
鉴于该语句产生了行锁，有事务信息，但是没有实际修改，可判断innodb在更新前后值一样时不会实际更新数据

老师提几个问题：
1.事务在执行过程中，binlog是否像redo log一样记录到binlog_cache里？
2.为什么把redo log buffer设置成全局参数，binlog cache设置为事务级别参数？
3.为什么一般是binlog落盘比redo log更耗时？
4.如果sync为1，dump线程是等到binlog 成功flush，再从binlog cache中把binlog event发送给从库？如果非1,是在最后xid写入就从binlog cache中把binlog event发送给从库？

问：2.追问5：binlog1丢失的原因是因为数据还在内存没刷到磁盘？如果设置innodb_flush_log_at_trx_commit=1 每次commit都刷到磁盘是不是就不会丢失了？这个两个理解有问题么？

Re:2. 追问5的回答的意思是，如果没有两阶段，redo log先提交完成再写binlog的话，就会导致binlog写入过程如果发生错误，无法回滚

老师您好，不好意思我没表达清楚，非常抱歉，重新问一遍，您文中的意思是【只用binlog做崩溃恢复，在图二crash位置，无法持崩溃恢复，图中binlog1已经commit了也会丢失】，
这段我没理解，为啥binlog1已经commit了还会丢失数据，所以引发了后面的思考
【binlog1丢失的原因是因为数据还在内存没刷到磁盘？如果设置innodb_flush_log_at_trx_commit=1 每次commit都刷到磁盘是不是就不会丢失了？】

由于工作的原因最近一段时间，没有看，为此这周末赶紧恶补了一下，在redo log和binlog的答疑中，写下自己的理解，老师帮忙看下哦
1、redo log和binlog采用两阶段提交，目的是为了双方能多一个选择，在mysql宕机时，如果redo log处于commit，事务直接提交，如果redo log处于prepare，binlog完整事务也提交，只有在binlog不完整时，事务会回滚，以前更新数据页会丢失。
2、redo log如何和binlog联系在一起，XID，在服务重启启动时，会扫描redo log中xid字段到binlog中，找相对应的事务，判断binlog的状态是否需要提交
3、能否在redo log写完整在写binlog么？不行，因为redo log写完，表示事务已经提交，如果在binlog写入的过程中出现异常，会导致redo log和binlog的数据不一致的问题，如果使用binlog恢复库，会导致主库和从库的数据不一致，因为redo log已提交，binlog没有写入成功，为此需要采用两阶段提交。
4、redo log和redo buffer的联系？
即在数据更新时，会先写redo buffer，因为这样可以在写redo log时，先把数据保存起来，在commit时在把数据写入redo log中，因为这样更新的时候会更快，直接更新内存，在事务处于cmmit时，才将内存中的数据写到redo log中。
5、数据页回复是使用buffer pool还是redo log？
redo log只有在数据页出现异常的时候，将其拿来恢复上次更新的数据页，但是redo log没有记录完整的数据页数据，为此在正常的情况下，都没有使用redo log，是使用buffer pool将起内部以前的数据刷新到磁盘中，其实想说，脏（这个字不会打，尴尬的一批）数据？
6、redo log一般设置多大？这个老师上面说的很清楚，如果磁盘的容量大，就多搞点，如果小的话可以向公司申请买好设备，要是不同意的话，就得问你们老板了，项目已si，开玩笑，哈哈哈。
7、只用redo log？其实你要是公司机器够大，可以设置成无限大，额，可以假装binlog，额，开玩笑的，因为redo log只有循环写，没法当做binlog，只要有钱就不好说了。
8、只用binlog？不行，为啥不行，百度啊，不行谷歌，好啦，开玩笑，发一下烧，因为如果在一个事务里面，同时写binlog，你看看会有什么问题，一个成功执行，一个执行失败，那会导致一个binlog可以回复数据页，一个不行，为此，导致数据页不一致，好了，今天不知道为啥那么兴奋，额，可能是，你猜吧，好了，写完我也忘了，一起拍砖

结论是方式3：
autocommit设置的是0

实验过程：
session1:
mysql> update t set a=2 where id=1;
Query OK, 0 rows affected (0.00 sec)
Rows matched: 1 Changed: 0 Warnings: 0
session2:
mysql> update t set a=2 where id=1;
ERROR 1205 (HY000): Lock wait timeout exceeded; try restarting transaction