共计 2124 个字符，预计需要花费 6 分钟才能阅读完成。
自动写代码机器人，免费开通
这篇文章主要介绍了 MySQL 日志之 redo log 和 binlog 的区别是什么，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让丸趣 TV 小编带着大家一起了解一下。
redo log 和 binlog 的区别
redo log
在 MySQL 中，如果你要更新一条语句，需要带更新条件，比如 update T set name =‘god-jiang’where id=6，一般都是先查询到 id= 6 的语句，然后再进行更新操作。
如果更新的数量是 100 条，1000 条甚至 10000 条的时候，每一次更新都需要写到磁盘上。然后磁盘也要找到对应的记录，然后再更新，整个过程 IO 成本、查找成本太大，为了解决这个问题，MySQL 的设计者采用了 WAL 技术来解决。WAL 全称是 Write Ahead Logging，意思就是先写日志，再写磁盘。
具体操作：当有一条记录需要更新的时候，InnoDB 引擎会先把记录写到 redo log 中，并更新内存，这个时候更新就算完成了。同时，InnoDB 引擎会在适当的时候（系统空闲时），将这个操作记录更新到磁盘中，这个更新往往是在系统比较空闲的时候。
但是 redo log 的大小是固定的，不可能一直无限写，让我们看下 MySQL 怎么做到的吧。
write pos 是当前记录的位置，一边写一边往后移动。check point 是当前要擦除的位置，也是往后移动并且循环的，擦除记录之前要把记录更新到数据文件中。
write pos 与 check point 之间绿色的部分表示可以记录新的操作。如果 write pos 追上了 check point，表示 redo log 满了，这个时候就不能继续执行新的操作，需要停下擦除一些记录，并且把 check point 往后推进。
有了 redo log，InnoDB 可以保证即使数据库发现异常重启了，也不会丢失之前提交的事务，这个能力也被称为 crash-safe。
以上就是 redo log 的介绍，看完了之后，你可以试着去问一下你公司的 DBA 同事，MySQL 是否可以恢复到半个月内任意一秒的状态，得到的答案肯定是可以的，这都要归功于 redo log 的功劳。
binlog
从 MySQL 整体来看，其实分为两层，一层是 Server 层，一层是存储引擎层。上面聊到的 redo log 就是属于 InnoDB 引擎特有的日志，而 binlog 是属于 Server 层的日志，也称为归档日志。
redo log 和 binlog 的区别
redo log 是 InnoDB 引擎特有的；binlog 是 MySQL 的 Server 层实现的，所有引擎都可以使用
redo log 是物理日志，记录的是“在 XXX 数据页上做了 XXX 修改”；binlog 是逻辑日志，记录的是原始逻辑，其记录是对应的 SQL 语句
redo log 是循环写的，空间一定会用完，需要 write pos 和 check point 搭配；binlog 是追加写，写到一定大小会切换到下一个，并不会覆盖以前的日志
通过简单的更新语句演示执行器和 InnoDB 引擎的内部流程
update T set name = god-jiang where id = 6通过执行器从 InnoDB 引擎取出 id= 6 的记录，然后加载到内存中
执行器拿到引擎返回的结果，把 name 修改为’god-jiang’，再重新调用存储引擎的接口写入新数据
引擎将新数据更新到内存中，同时将这个更新操作写到 redo log 中，此时 redo log 处于 prepare 状态
执行器生成这个操作的 binlog，并把 binlog 写到磁盘中
执行器调用引擎提交事务的接口，并且把刚刚写入的 redo log 改为 commit 状态，更新完成
对应的流程图 
最后为什么写入 redo log 会处于 prepare 状态，然后写入 binlog 还要变成 commit 状态？其实这个过程就叫做“两阶段提交”。
两阶段提交
其实 redo log 和 binlog 都可以用于表示事务的提交的状态，而两阶段提交就是让这两个状态保持逻辑上的一致。
举例子：update T set name =‘god-jiang’where id = 6 没有两阶段提交会发生什么？
先写 redo log 后写 binlog。假设写完了 redo log，binlog 还没有写完，这个时候 MySQL 异常重启。因为 redo log 写完了，恢复系统的时候 name=‘god-jiang’。但是 binlog 没有写完，所以 binlog 没有记录这条语句，这个时候用 binlog 恢复数据的时候，恢复出来的 name 就是原来值，与 redo log 不同。
同理可得，先写 binlog 后写 redo log 也会发现两个日志恢复的数据不同。这个不一致会导致线上出现主从不一致的情况。
总结
redo log 可以保存 crash-safe 能力，可以保证 MySQL 异常重启数据不丢失
binlog 可以记录对应的 SQL 语句，也可以保证 MySQL 异常重启数据不丢失
提交事务的两阶段提交，可以维持数据逻辑一致性
感谢你能够认真阅读完这篇文章，希望丸趣 TV 小编分享的“MySQL 日志之 redo log 和 binlog 的区别是什么”这篇文章对大家有帮助，同时也希望大家多多支持丸趣 TV，关注丸趣 TV 行业资讯频道，更多相关知识等着你来学习!
向 AI 问一下细节
