查询语句：经过连接器、分析器、优化器、执行器等功能模块，最后到达存储引擎。更新同样
表创建语句，主键 ID 和整型字段 c：mysql> create table T(ID int primary key, c int);
将 ID=2 行值+ 1，：mysql> update T set c=c+1 where ID=2;
连接器：先连接数据库
分析器：通过词、语法解析知道这是更新语句。
优化器：决定用 ID 索引
执行器：找到这一行，更新。
与查询流程不同：更新流程还涉日志模块，redo log（重做日志）和 binlog（归档日志，MySQL 可恢复到半个月内任意一秒）。
一、重要的日志模块：redo log
酒店掌柜粉板，记录客人赊账记录。赊账人不多写板上。人多记不下，写赊账账本。
还账：1.账本扣除掉；2.粉板记下，打烊后账本核算。
生意红火时，先粉板记下。不用每次翻账本，效率低
MySQL 里，每次更新都写进磁盘，磁盘找到对应记录再更新， IO 、查找成本都高。用了类似粉板思路提升效率。
WAL （Write-Ahead Logging）：粉板、账本整个过程，先写日志，再写磁盘。
更新时InnoDB 引擎把记录写到 redo log（粉板）更新内存，更新算完成。InnoDB 引擎空闲（系统比较时）时更新到磁盘，
如果赊账特别多，粉板写满，更新粉板部分到账本腾空间。
InnoDB 的 redo log 固定大小，配置一组 4 个文件，每个1GB，“粉板”总共可以记录 4GB。写到末尾就又回到开头循环写，
write pos ：当前记录的位置，边写边后移，写 3 号尾后就回0 号头。
checkpoint ：当前要擦除的位置，后推移且循环，擦除前更新到数据文件。
write pos 和 checkpoint 之间：“粉板”空着部分。write pos 追上 checkpoint“粉板”满
redo log，保证InnoDB异常重启，之前提交记录不丢失，这个能力为crash-safe。停业恢复生意后，依然明确赊账账目。
二、重要的日志模块：binlog
MySQL 整体两块：Server （MySQL 功能层面）；引擎层（存储）。redo log 是 InnoDB 引擎特有日志，Server 层日志为 binlog（归档日志）。
为什么会有两份日志呢？开始 MySQL 没有 InnoDB 。自带引擎 MyISAM（不能crash-safe，binlog也不能）。不同：
1. redo log InnoDB 引擎特有；binlog 所有引擎都可用。
2. redo log 物理日志，记录“某个数据页修改什么”；binlog 逻辑日志，语句原始逻辑，“给 ID=2 这行c 字段加 1 ”。
3. redo log 循环写，空间固定会用完；binlog 可追加写。写到一定大小后会切换下一个，不会覆盖以前日志。
执行器和 InnoDB 引擎 update 语句时内部流程：
1. 执行器先找引擎取 ID=2 这行。引擎树搜索。内存中，返回给执行器；否则从磁盘读入内存，再返回。
2. 执行器加 1，得新数据，调用引擎接口写入。
3. 引擎更新到内存，同时记录 redo log （prepare 状态）里， 告知执行器完成，可以提交事务。
4. 执行器生成这个操作 binlog，写入磁盘。
5. 执行器调用引擎的提交事务接口，引擎把redo log 改成（commit）状态，更新完成。
浅色：InnoDB 内部执行，深色：执行器中执行。
最后三步有点“绕”，将 redo log 写入拆成了两步：prepare 和 commit，这就是"两阶段提交"。
三、两阶段提交
两份日志一致。
怎样让数据库恢复到半个月内任意一秒的状态？
binlog “追加写”记录操作，半个月内可恢复，保存最近半个月所有 binlog，定期（天/周）整库备份。
误删表，找最近的一次全量备份，运气好昨晚上备，恢复到临时库；从备份时间点开始， binlog 取出重放误删表之前
为什么“两阶段提交”。
redo log 和 binlog 两个独立逻辑，update例子， ID=2 的行， c 值 0，执行 update 写完第一个日志后，第二个日志还没写完 crash，数据库和日志恢复的库的不一致：
1. 先写 redo log 后写 binlog。binlog 没写完异常重启。用binlog 恢复临时库，与原库的值不同。
2. 先写 binlog 后写 redo log。binlog 恢复时多一个事务， c 值 1，与原库值不同。
概率不低，恢复临时库场景：扩容时，全量备份+ binlog 实现
小结
redo log ：保证 crash-safe 能力。innodb_flush_log_at_trx_commi t= 1 时（建议），每次事务 redo log 直接持久化到磁盘。保证 MySQL 异常重启数据不丢失。
sync_binlog =1 ，每次事务binlog 持久化到磁盘。重启后 binlog 不丢失。“两阶段提交”，维持一致性
问题：定期全量备份的周期“取决于系统重要性，一天/周一备，什么场景一天一备好？或者说，影响数据库系统哪个指标？
评论1
如果mysql只有InnoDB引擎了，redo来实现复制，oracle的DG就诞生了，物理的速度也将远超逻辑的，毕竟只记录了改动向量
binlog几大模式，一般采用row，因为遇到时间，从库可能会出现不一致的情况，row更新前后都有，会导致日志变大
一天一备，按天找，数据库丢失好找
一周一备，周一要恢复周日某个时间点，一周全部binlog用来恢复，看业务能忍受程度。
评论2
redo log写满，事务均未提交，要擦除redo log，被修改的脏页被迫flush到磁盘，数据commit之前持久化到磁盘中。mysql会如何处理？
1prepare阶段 2写binlog 3commit
2、之前崩溃，重启恢复：回滚。备份：没有binlog 。一致
3、之前崩溃，重启恢复：自动commit。备份：有binlog. 一致
评论3
完整交易过程：账本记卖一瓶可乐（redo log为 prepare状态），收钱（bin log记录），账本打勾（redo log置为commit）
收钱打断，只记账没收钱，失败，回滚；
收钱后终止，有记录（prepare），钱箱有收入（bin log），完善账本（commit），交易有效。
