针对不能只用binlog完成数据恢复我的理解： 按照文中这个话题下的示例，因为MySQL写数据是写在内存里的，不保证落盘，所以commit1的数据也可能丢失；但是恢复只恢复binlog失败的也就是commit2的数据，所以数据会丢失。 这样理解对吗？

看到自己的问题上榜，这是对自己的最大鼓励。 学习专栏之前，自己只是一个 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 就解决了呢，哈哈哈哈。后面有事，没有继续跟进他这问题了。 非常感恩，跟着老师学习，让我体会到了学习是一件自然而又充满魅力的事情，也让我从一个基础不牢固的小白，一步步地充实了自己的知识库，另外老师非常尽责，经常半夜回复答疑，希望老师保重身体。谢谢！！

课后问题： 在命令行先执行以下命令（注意不要提交事务）： 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版本的数据是不可见的，这就违反了“当前读的规则”。 以上是我的理解与分析，不是很确定准确与否。

孔乙己来到酒馆大喊一声老板来二两酒赊着,酒馆生意太好,老板把孔乙己的欠账记录记到小黑板上并记录了孔乙己点的菜单。孔乙己跟别人吹了会牛,忘了叫的几两酒了。又给老板说,老板把酒改成二两。老板也不确定孔乙己叫没叫酒,就去查菜单,发现孔乙己确实点了酒,但是本来就二两,也就难得麻烦了,又要修改小黑板,又要改菜单。直接就给孔乙己说已经改好了。😄

林老师的每次更新我都会跟着看 跟着学 已经坚持15节课了 受益良多 只是心里有时会反问自己 底层原理有那么重要吗？ 会用不就行了吗？ 自己不知道该怎么推翻这些想法 加上自己有个不好的习惯 就是容易放弃 希望自己能够坚持到最后。

在极客时间也学了不少课程，林老师是这其中最认真负责的，好的课程是用“心”写出来的

【操作符“|”是逻辑或，连同最后一句insert语句里...】 老师，“|” 这应该叫位运算符的按位或操作符，逻辑或是“||”吧？ 这里的幂等性原理就是：A < B: relation_ship = 2 | 1; A > B:relation_ship = 1 | 2；重复插入 3 | 1 或者 3 | 2 。位运算： 2 | 1 == 1 | 2 == 3 | 1 == 3 | 2 == 3。感觉这里想法很巧妙。

关于刷脏页有两个问题请教老师: 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是怎么清除掉关于这个脏页的所有记录的?

老师您好，读了很久其他问题都明白了，还是没太明白只用binlog为啥不能恢复数据，根本原因还是对binlog和redolog都记录的内容没掌握清楚，我的理解跟评论区里“得不到de颜色”说的一样，就是binlog也同样记录了一行数据，但是不知道该从哪里回放，所以没法恢复，但是redo log可以从check_point开始扫描所以能恢复； 看到你回复的是binlog没有能力做出来一页的数据，反正缺失的数据都记在binlog里了，如果能有办法知道binlog从哪里回放，回放一遍就可以了，为啥一定要做一页数据出来，麻烦老师解答一下，谢谢

如果图1的“写入redo log”是写内存，当时刻B发生crash，重启后这部分redo log都丢失了，那么何谈判断redo log是否有完整的prepare还是commit标志呢？