日志系统：一条SQL更新语句是如何执行的？
建议大家有需求可以上极客学院买一份，名字就叫Mysql实战45讲，确实写的不错。
更新数据库时，会涉及到两个重要的日志模块，redo log（重做日志）和binlog（归档日志）。这玩意在公司，天天听到，这次大概知道是什么东西了。
重要的日志模块：redo log
Mysql采用了WAL技术，也就是Write-Ahead Logging。可以理解为先写日志，再写磁盘。
更新语句执行时，InnoDB会把更新的记录先写到redo log中，并更新到"内存"中。然后InnoDB引擎会在可适当的时候（就是数据库较为空闲的时候）将这个操作更新到磁盘中。
redo log是在数据库磁盘上固定大小的空间，是循环读写的。个人理解就是在4G的空间（可以配置为4个文件）里循环读写，只要记住头尾指针。头指针写入数据，尾指针察除数据，并更新数据到数据库磁盘中。因为指针的读写就是一个顺序操作，而更新需要找到原记录然后再更新，顺序操作更快。相当于一个缓存的作用。
当然如果两个指针相遇了，就理解这个redo log写满了，那就只能等尾指针更新完才能操作。
redo log,可以理解为即时数据库异常重启了，之前提交的记录都不会丢失，这个能力称为crash-safe。
重要的日志模块：binlog
redo log是InnoDB引擎特有的日志，Server层也有自己的日志，binlog(归档日志)。
两种日志的差异
- redo log是InnoDB引擎特有的;binlog是MySql的Server层实现的，所有引擎都可以使用
- redo log是物理日志，记录的是在某个数据也上做了什么修改;binlog是逻辑日志，记录的是这个语句的原始逻辑，比如"给ID=2"这一行的c字段加1
- redo log 是循环写，空间固定。binlogs是追加写，是只binlog文件到了一定大小后切换下一个，并不会覆盖以前的日志。
使用执行器和InnoDB引擎执行update语句时的内部流程
update T set c=c+1 where ID=2;
- 执行器先找到引擎取ID=2这一行，ID是主键，引擎直接用树搜索到这一行，如果ID这一行所有的数据页本来就在内存中，就直接返回给执行器。 否则从磁盘读入内存，然后再返回。
- 执行器拿到引擎给的行数据，然后得到更新后的数据，再调用引擎接口写入这行新数据
- 引擎将这行新数据更新到内存中，然后同时更新到redo log中，此时redo log处于prepare状态。然后告诉执行器执行成功，然后提交事物。
- 执行器生成这个操作的binlog，并把binlog写入磁盘。
- 执行器调用引擎的提交事物接口，引擎把刚刚写入redo log改成提交状态，更新完成
设置
redo log用于保证crash-safe能力。innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，标识每次事物的redo log都直接持久化到磁盘。这样可以保证Mysql异常重启后数据不丢失。
sync_binlog 这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘，这样可以保证 MySQL 异常重启之后 binlog 不丢失。
个人理解，两个日志的场景保证了整个数据库的闭环逻辑。无论哪种情况，都可以恢复数据。
