MySQL的三种日志

发表于2018-03-20|更新于2026-05-01|SQL

|总字数:496|阅读时长:1分钟|浏览量:

redo log日志也叫做WAL技术（Write- Ahead Logging），他是一种先写日志，并更新内存，最后再更新磁盘的技术，为了就是减少sql执行期间的数据库io操作，并且更新磁盘往往是在Mysql比较闲的时候，这样就大大减轻了Mysql的压力。

redo log是固定大小，是物理日志，属于InnoDB引擎的，并且写redo log是环状写日志的形式：

如上图所示：若是四组的redo log文件，一组为1G的大小，那么四组就是4G的大小，其中write pos是记录当前的位置，有数据写入当前位置，那么write pos就会边写入边往后移。

check point记录擦除的位置，因为redo log是固定大小，所以当redo log满的时候，也就是write pos追上check point的时候，需要清除redo log的部分数据，清除的数据会被持久化到磁盘中，然后将check point向前移动。

redo log日志实现了即使在数据库出现异常宕机的时候，重启后之前的记录也不会丢失，这就是crash-safe能力。

binlog称为归档日志，是逻辑上的日志，它属于Mysql的Server层面的日志，记录着sql的原始逻辑，主要有两种模式：一个是statement格式记录的是原始的sql，而row格式则是记录行内容。

redo log和binlog记录的形式、内容不同，这两者日志都能通过自己记录的内容恢复数据。

之所以这两个日志同时存在，是因为刚开始Mysql自带的引擎MyISAM就没有crash-safe功能的，并且在此之前Mysql还没有InnoDB引擎，Mysql自带的binlog日志只是用来归档日志的，所以InnoDB引擎也就通过自己redo log日志来实现crash-safe功能。

redolog 是重做日志，提供前滚操作，

undolog是回滚日志，提供回滚操作。

binlog 是归档日志

文章作者: Michael

文章链接: https://mikeah2011.github.io/post/01_MySQL/redo%20log%20%E5%92%8C%20binlog.html

版权声明: 本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 Michael's Blog！

相关推荐

SQL语句性能分析工具 - explain

通过explain，如以下例子： 1EXPLAIN SELECT * FROM employees.titles WHERE emp_no='10001' AND title='Senior Engineer' AND from_date='1986-06-26'; id select_type table partitions type possible_keys key key_len ref filtered rows Extra 1 SIMPLE titles null const PRIMARY PRIMARY 59 const,const,const 10 1 id：在⼀个⼤的查询语句中每个SELECT关键字都对应⼀个唯⼀的id ，如 explain select * from s1 where id = (select id from s1 where name = 'egon1'); 第一个select的id是1，第二个select的id是2。有时候会出现两个sel...

MVCC叫做多版本控制，实现MVCC时用到了一致性视图，用于支持读提交和可重复读的实现。对于一行数据若是想实现可重复读取或者能够读取数据的另一个事务未提交前的原始值，那么必须对原始数据进行保存或者对更新操作进行保存，这样才能够查询到原始值。在Mysql的MVCC中规定每一行数据都有多个不同的版本，一个事务更新操作完后就生成一个新的版本，并不是对全部数据的全量备份，因为全量备份的代价太大了：如图中所示，假如三个事务更新了同一行数据，那么就会有对应的v1、v2、v3三个数据版本，每一个事务在开始的时候都获得一个唯一的事务id（transaction id），并且是顺序递增的，并且这个事务id最后会赋值给row trx_id，这样就形成了一个唯一的一行数据版本。实际上版本1、版本2并非实际物理存在的，而图中的U1和U2实际就是undo log日志（回滚日志），这v1和v2版本是根据当前v3和undo log计算出来的。 InnoDB引擎就是利用每行数据有多个版本的特性，实现了秒级创建“快照”，并不需要花费大量的是时间。

SQL查询语句的流程

当Mysql执行一条查询的SQl的时候大概发生了以下的步骤：客户端发送查询语句给服务器。服务器首先进行用户名和密码的验证以及权限的校验。然后会检查缓存中是否存在该查询，若存在，返回缓存中存在的结果。若是不存在就进行下一步。注意：Mysql 8就把缓存这块给砍掉了。接着进行语法和词法的分析，对SQl的解析、语法检测和预处理，再由优化器生成对应的执行计划。 Mysql的执行器根据优化器生成的执行计划执行，调用存储引擎的接口进行查询。服务器将查询的结果返回客户端。 Mysql中语句的执行都是都是分层执行，每一层执行的任务都不同，直到最后拿到结果返回，主要分为Service层和引擎层。在Service层中包含：连接器、分析器、优化器、执行器。引擎层以插件的形式可以兼容各种不同的存储引擎，主要包含的有InnoDB和MyISAM两种存储引擎。具体的执行流程图如下所示：

MySQL主从复制与读写分离

主从同步 master主库，有数据更新，将此次更新的事件类型写入到主库的binlog文件中主库会创建log dump 线程通知slave有数据更新 slave从库，向master节点的 log dump线程请求一份指定binlog文件位置的副本，并将请求回来的binlog存到本地的Relay log 中继日志中 slave 再开启一个SQL 线程读取Relay log事件，并在本地执行redo操作。将发生在主库的事件在本地重新执行一遍，从而保证主从数据同步主从延迟指一个写入SQL操作在主库执行完后，将数据完整同步到从库会有一个时间差，称之为主从延迟。主库生成一条写入SQL的binlog，里面会有一个时间字段，记录写入的时间戳 t1 binlog 同步到从库后，一旦开始执行，取当前时间 t2 t2-t1，就是延迟时间注意：不同服务器要保持时钟一致。主从延迟排查方法通过 show slave status 命令输出的Seconds_Behind_Master参数的值来判断为零：表示主从复制良好正值：表示主从已经出现延时，数字越大，表示从库延迟...

事务概念 4个原则 ACID 原则概念原子性一个事务中的操作要么全部成功，要么全部失败 Atomicity 一致性总是从一个一致性的状态转换到另一个一致性的状态 Consistent 隔离性一个事务的修改在提交前，其他事务是感知不到的 Isalotion 持久性永久保存在数据库中 Durable 原子性、隔离性、持久性都是为了保障一致性而存在的，一致性也是最终的目的。隔离级别读未提交 READ UNCOMMITTED 读已提交 READ COMMITTED 可重复读 REPEATABLE READ 可序列化 SERIALIZABLE 没有那种隔离级别是完美的，只能根据自己的项目业务场景去评估选择最适合的隔离级别，大部分的公司一般选择Mysql默认的隔离级别：可重复读。隔离级别从：读未提交-读提交-可重复读-串行化，级别越来越高，隔离也就越来越严实，到最后的串行化，当出现读写锁冲突的时候，后面的事务只能等前面的事务完成后才能继续访问。读未提交：读取到别的事务还没有提交的数据，从而产生了脏读。读提交：...

覆盖索引（Covering Index）

一句话覆盖索引 = 一个 SELECT 需要的所有字段，都能从二级索引里直接拿到，不需要回表。 EXPLAIN 显示 Using index 就是覆盖了。一、为什么需要覆盖InnoDB 的二级索引存的是主键值，不是数据行： 123456SELECT name FROM users WHERE age = 25;-- 走 idx_age 二级索引-- → 拿到主键 id 列表-- → 用 id 回到聚簇索引取整行 ← 这一步叫"回表"-- → 取出 name 回表 = 一次随机 IO。如果二级索引里直接就有 name，就省了这一步。二、用联合索引覆盖12345678-- ❌ 普通索引，需要回表ALTER TABLE users ADD INDEX idx_age (age);SELECT name FROM users WHERE age = 25;-- ✅ 覆盖索引，name 直接在索引里ALTER TABLE users ADD INDEX idx_age_name (age, name);SELECT name FROM u...

评论