2.MySQL三大日志文件

2.1日志文件列表

1. redo log：重做日志，记录了对于 InnoDB 表的每个写操作，不是 SQL 级别的，而是物理级别的，主要用于崩溃恢复
2. undo log：回滚日志，记录数据被修改前的值，用于事务的回滚
3. bin log：二进制日志，记录了所有修改数据库状态的 SQL 语句，以及每个语句的执行时间，如 INSERT、UPDATE、DELETE 等，但不包括 SELECT 和 SHOW 这类的操作
4. slow query log：慢查询日志，记录执行时间超过 long_query_time 值的所有 SQL 语句。这个时间值是可配置的，默认情况下，慢查询日志功能是关闭的。可以用来识别和优化慢 SQL
5. error log：错误日志，记录 MySQL 服务器启动、运行或停止时出现的问题

2.1.1 redo log

1. redo log，重做日志
2. 内容： 物理格式的日志，记录的是物理数据页面的修改的信息，其 redo log 是顺序写入 redo log file 的物理文件中去的
3. 作用： 确保事务的持久性。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启 mysql 服务的时候，根据 redo log 进行重做，从而达到事务的持久性这一特性

2.1.2 bin log

1. bin log，二进制日志
2. 内容： 所有执行增删改的SQL 语句，以及每个语句的执行时间，以便进行数据恢复和主从复制
3. 作用： 用于复制，在主从复制中，从库利用主库上的 binlog 进行重播，实现主从同步。 用于数据库的基于时间点的还原

2.1.3 undo log

1. undo log，回滚日志
2. 内容： 逻辑格式的日志，在执行 undo 的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于 redo log 的
3. 作用： 保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

2.2redo log日志详讲

1. 原因：mysql，如果每次更新操作都要写进磁盘，然后磁盘要找到对应记录，然后再更细，整个过程 io 成本、查找成本都很高
2. 解决方案：WAL 技术（Write-Ahead Logging）。先写日志，再写磁盘
3. 具体过程：
   1. 当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log 里面，并更新内存，这个时候更新就算完成了。
   2. 同时，InnoDB 引擎会在适当的时候，将这个操作记录更新到磁盘里面，而这个更新往往是在系统比较空闲的时候做。
   3. InnoDB 的 redo log 是固定大小的，比如可以配置为一组 4 个文件，每个文件的大小是 1GB，那么总共就可以记录 4GB 的操作。从头开始写，写到末尾就又回到开头循环写

2.3 binglog和redo log有什么区别？

1. 文件级别不同：
   1. redo log 是 InnoDB 引擎特有的
   2. binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用
2. 文件内容不同：
   1. redo log 是物理日志，记录的是 “在某个数据页上做了什么修改”
   2. binlog 是逻辑日志，记录的是这个语句的原始逻辑，比如 “给 ID=2 这一行的 c 字段加 1
3. 文件写入不同：
   1. redo log 是循环写的，空间固定会用完；
   2. binlog 是可以追加写入的。“追加写” 是指 binlog 文件写到一定大小后会切换到下一个，并不会覆盖以前的日志

2.4一条更新语句的执行过程

1. 执行器先找引擎取 ID=2 这一行。ID 是主键，引擎直接用树搜索找到这一行。如果 ID=2 这一行所在的数据页本来就在内存中，就直接返回给执行器；否则，需要先从磁盘读入内存，然后再返回。
2. 执行器拿到引擎给的行数据，把这个值加上 1，比如原来是 N，现在就是 N+1，得到新的一行数据，再调用引擎接口写入这行新数据。
3. 引擎将这行新数据更新到内存中，同时将这个更新操作记录到 redo log 里面，此时 redo log 处于 prepare 状态。然后告知执行器执行完成了，随时可以提交事务。
4. 执行器生成这个操作的 binlog，并把 binlog 写入磁盘。、
5. 执行器调用引擎的提交事务接口，引擎把刚刚写入的 redo log 改成提交（commit）状态，更新完成