日志系统：一条sql更新语句是如何执行的--丁奇mysql45讲笔记

• 更新语句和查询语句一样都会走和查询一样的流程即
  连接器–>分析器–>优化器–>执行器
  1 如果对一个表进行更新 这个表的缓存会失效这也是不建议用查询缓存的原因
  2 分析器会通过语法解析知道是条更新语句
  3 优化器决定要使用ID这个索引
  4 执行器负责执行找到 数据进行更新操作
• 与查询语句不同的是更新流程涉及到两个重要的日志模块redo log 和 binlog 总结如下
  1 redolog ： InnoDB 特有 将记录写到redolog 中 并更新内存，这个时候更新就算完成了 同时 innoDB引擎会再适当的时候讲这个操作记录更新到磁盘中，如果更新的特别多 redolog是固定大小的 就会停下来将更新到数据库中然后擦除初始数据进行记录 如下图
  
  write pos 是当前记录的位置，一边写一边后移，写到第 3 号文件末尾后就回到 0 号文件开头。checkpoint 是当前要擦除的位置，也是往后推移并且循环的，擦除记录前要把记录更新到数据文件。write pos 和 checkpoint 之间的是“粉板”上还空着的部分，可以用来记录新的操作。如果 write pos 追上 checkpoint，表示“粉板”满了，这时候不能再执行新的更新，得停下来先擦掉一些记录，把 checkpoint 推进一下。有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失，这个能力称为 crash-safe。
  2 binlog 前面提到的redolog 是引擎层的日志记录 而binlog 是server层的日志记录

总结：
物理日志 redolog 逻辑日志 binlog

1. redolog 保证crash-safe能力，innodb_flush_log_at_trx_commit 这个参数设置成1的时候，每次事务的redolog 都直接持久化到磁盘
2. sync_binlog 这个参数设置成1 的时候，表示每次事务的binlog都持久化到磁盘。这个参数我也建议你设置成1 这样可以保证mysql 异常重启后binlog不丢失