日志系统：一条SQL更新语句是如何执行的

• SQL语句

CREATE TABLE t(id int primary key,c int);
UPDATE t SET c=c+1 WHERE id=2

• 执行流程：
  • 首先建立数据库连接
  • 把要查询的表上的查询缓存结果全部清空
  • 分析器会通过词法分析和语法分析得知这是一条更新语句。
  • 优化器决定使用id这个索引
  • 执行引擎负责具体执行，找到这一行，然后更新
• 与查询流程不一样：更新流程还涉及到两个重要的日志模块：redo log（重做日志），bin log(归档日志)

日志模块：redo log

问题：如果每次更新操作都要写磁盘，然后磁盘也要找到对应的那条记录，再去更新，整个过程的IO成本，查找成本都很高，为了解决这个问题，设计者采用WAL的技术来提升更新效率

• WAL(write-ahead logging)关键点是先写日志，再写磁盘。具体来说当有一条记录需要更新时，Innodb引擎就会先把记录写到redo log里，并更新内存，这个时候更新就算完成。同时在适当的时候刷新到磁盘里，而这个更新往往是在系统比较空闲的时候做
• redo log是固定大小的，比如可以配置为一组4个文件，每个文件大小为1GB,那么总共可以记录4GB的操作。从头开始写，写到末尾就又回到开头循环写
• write pos是当前记录的位置，一边写一边后移，写到3号文件末尾就回到0号文件开头。checkpoint是当前要擦除的位置，也是往后推移并循环的，擦除记录前要把记录更新到数据文件
• write pos和checkpoint之间空着的部分，可以用来记录更新操作。如果write pos追上checkpoint表示记录满了，不能再执行新的更新。得停下来更新到磁盘
• 有了redo log,InnoDB就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为crash-safe

日志模块 binlog

• mysql整体来看，分为两块：
  • server层负责功能层面的事情，而server层也有自己的日志：bin log
  • 引擎层，负责存储相关的事宜，redo log属于引擎层特有的日志，
• redo log和bin log的区别
  • redo log是Innodb引擎特有的；binlog是server层实现的，所有引擎都可以使用
  • redo log是物理日志，记录的是“在某个数据页上做了什么修改”，bin log是逻辑日志，记录的是这个语句的原始逻辑
  • redo log是循环写的，空间固定会用完；binlog是可以追加写的，追加写是指binlog文件写到一定大小后会切换下一个，并不会覆盖之前的日志
• 执行器和InnoDB引擎执行更新时的内部流程
  • 执行器先找引擎取id=2这一行，id是主键，直接使用聚簇索引树找到这一行，如果id=2这一行所在的数据页本来就在内存中，就直接返回给执行器，否则需要先从磁盘读入内存，然后再返回
  • 执行器拿到引擎给的行数据，把这个值甲乙，得到新的一行数据，再调用引擎写入这行新数据
  • 引擎将这行新数据更新到内存中，同时将这个更新操作记录到redo log里面，此时redo log处于prepare状态，然后告知执行器执行完成了，随时可以提交事务
  • 执行器生成这个操作的binlog并把binlog写入磁盘
  • 执行器调用引擎的提交事务接口，引擎把刚刚写入的redo log改成提交状态，更新完成
• redo log的写入拆为两个步骤：prepare和commit，这就是两阶段提交

两阶段提交

如何让数据库恢复到半个月内任意一秒的状态

• 前提条件:系统一定保存最近半个月的所有binlog，同时做定期的整库备份（一天一备份或者一周一备份）
• 找到距离删表最近的一次全量备份，从这个备份恢复到临时库
• 从备份的时间点开始，将备份的binlog依次取出，重放到误删表之前的那个时间段

为什么需要两阶段提交 由于redo log和binlog是两个独立的逻辑，如果不用两阶段提交，要么先写redo,后写binlog,要么先写binlog后写redo

• 先写redo log,再写binlog:假设在redo log写完，binlog还没写入就异常重启。redolog写完之后即使系统宕机仍然能够恢复数据，但是由于binlog没写，之后需要用到bin log恢复的话，就少了一次更新，和原库不同
• 先写binlog,再写redo log:假设写完binlog之后宕机，由于redo log还没写，崩溃之后事务失效，并未真实更新。但是后续使用bin log恢复的话多了更新语句，恢复出来也与原库不一致

如果不使用两阶段提交，数据库的状态有可能和用它的日志恢复出来的库状态不一致

• 使用场景：扩容的时候，需要再多加一套备库来增加系统的读能力，如果不使用两阶段提交，导致线上出现主从不一致的情况
• 简单来说：redo log和binlog都可以表示事务的提交状态，而两阶段提交就是让两个状态保持逻辑一致