redo log的缺点

我们都知道，事务的四大特性里面有一个是持久性，具体来说就是只要事务提交成功，那么对数据库做的修改就被永久保存下来了，不可能因为任何原因再回到原来的状态。那么mysql是如何保证一致性的呢？最简单的做法是在每次事务提交的时候，将该事务涉及修改的数据页全部刷新到磁盘中。但是这么做会有严重的性能问题，主要体现在两个方面： 1）、 因为Innodb是以页为单位进行磁盘交互的，而一个事务很可能只修改一个数据页里面的几个字节，这个时候将完整的数据页刷到磁盘的话，太浪费资源了！ 2）、 一个事务可能涉及修改多个数据页，并

在事务的实现机制上，MySQL采用的是WAL（Write-ahead logging，预写式日志）机制来实现的。 在使用WAL的系统中，所有的修改都先被写入到日志中，然后再被应用到系统中。通常包含redo和undo两部分信息。 为什么需要使用WAL，然后包含redo和undo信息呢？举个例子，如果一个系统直接将变更应用到系统状态中，那么在机器掉电重启之后系统需要知道操作是成功了，还是只有部分成功或者是失败了（为了恢复状态）。如果使用了WAL，那么在重启之后系统可以通过比较日志和系统状态来决定是继续完成操作还

MySQL 中的Binlog是一种记录数据库所有修改操作的日志文件，主要用于数据复制崩溃恢复和数据恢复。它能够帮助 MySQL 在主从复制架构中同步数据，并支持点-in-time 恢复。Binlog 采用二进制格式，支持多种格式（语句型、行型、混合型），并且可以通过配置文件进行启用和管理。Redo Log是 InnoDB 存储引擎中至关重要的组件，主要用于保证事务的持久性和崩溃恢复。它通过记录事务的修改操作来确保数据不会丢失，并在崩溃恢复时重做提交的事务。你可以通过配置和。

redo log用于记录事务操作变化，记录的是数据被修改之后的值，（tbs space id + page no + action）。尚未完成的DML,数据库崩溃则用log恢复。保证事务持久性。1在页面修改完成之后，脏页刷入磁盘之前，写入Redo日志；2实现WAL:日志比数据页先写回磁盘3聚簇索引二级索引Undo页面修改，记录Redo日志；4至少要有2个redo log，文件名序号从0开始，从ib_logfile0到ib_logfileN#redo log。

MySQL 日志 主要包括错误日志、查询日志、慢查询日志、事务日志、二进制日志几大类。其中，比较重要的还要属二进制日志 binlog（归档日志）和事务日志 redo log（重做日志）和 undo log（回滚日志）。1、重做日志（redo log）2、回滚日志（undo log）3、归档日志（binlog）4、错误日志（errorlog）5、慢查询日志（slow query log）6、一般查询日志（general log）7、中继日志（relay log）

三大日志系统犹如数据库的 "三驾马车"：redo log 保障数据不丢失，undo log 维护事务原子性与数据多版本，bin log 构建增量复制与恢复体系。理解它们的底层原理，不仅能帮助我们优化数据库性能，更能在故障处理、架构设计时做出正确决策。当遇到事务异常、主从延迟或空间占用过高等问题时，从这三大日志入手分析，往往能快速定位到核心原因。

`redo log buffer`刷盘到`redo log file`的过程并不是真正的刷到磁盘中去，只是刷入到 `文件系统缓存（page cache）`中去（这是现代操作系统为了提高文件写入效率做的一个优化），真正的写入会交给系统自己来决定（比如page cache足够大了）。那么对于InnoDB来说就存在一个问题，如果交给系统来同步，同样如果系统宕机，那么数据也丢失了（虽然整个系统宕机的概率还是比较小的）

介绍了 MySQL 中 redo log 的两阶段提交的必要性

redo log默认情况下存储在data目录下ib_logfile0 、ib_logfile1，可以通过 innodb_log_file_size 设置大小， innodb_log_files_in_group 设置文件个数，比如可以配置为一组4个文件，每个文件的大小是 1GB，整个redo log 日志文件组可以记录4G的内容，2、先写redo log，mysql崩溃，重启，通过redo log恢复事务，但是binlog里并没有这个事务，主从不一致，如果通过binlog来恢复数据，也会丢失事务。

InnoDB使用Buffer Pool来加速数据读写，提升性能的同时也带来了一些问题，为了避免页面频繁刷盘和磁盘随机写，InnoDB引入了WAL机制，先顺序写少量的redo log，再由后台线程去异步刷脏页，尽可能提升SQL的执行效率。写redo log的好处是：相较于一个完整的页，redo log占用的空间极小，而且它是顺序写的，比随机写的效率更高。根据不同的修改场景，InnoDB设计了几十种不同类型的redo log。这里面包含极其简单的物理日志，只是单纯记录了要把哪个页面的哪些数据做修改；

引言 这篇文章说下MySQl中的恢复日志中的binlog和redolog。 binlog binlog称为二进制日志或者归档日志，主要记录除查询以外的操作（delete、update、insert、DML等），主要用于主从复制和数据恢复。 binlog的数据格式有如下三种 格式 做法 优点 缺点 STATEMENT 直接记录相关的SQL语句，在恢复的时候直接执行SQL语句 数据量小，节省磁盘IO 由于某些函数UUID()、NOW()等函数，并且需要上下文关联，容易造成主从复制不一致 RO

聚簇索引和非聚簇索引的主要区别在于索引的组织方式和数据存储位置。聚簇索引决定了表中数据的物理存储顺序，一个表只能有一个聚簇索引；而非聚簇索引是独立于数据存储的额外结构，一个表可以有多个非聚簇索引。聚簇索引的叶子节点直接包含数据行，而非聚簇索引的叶子节点包含的是指向数据行的指针。

mysql 实现列转行和行转列

本文介绍了在Ubuntu 20.04/22.04无网络环境下部署MySQL的方法。首先需要准备虚拟机环境和下载依赖包，建议初学者先手动部署以理解原理。主要步骤包括：挂载ISO文件、安装MySQL、启动服务、设置root密码和远程访问配置。文中提供了详细的命令操作，并推荐使用自动部署脚本mysql_offline_deploy.sh完成批量部署。脚本包含挂载ISO、安装MySQL、安全设置和开放端口等功能。最后提供了补充建议，如扩展依赖包和使用tar.gz格式替代ISO等方案。

MySQL的日志有很多种类，最终要的有三种，binlog、redo log和undo log日志。他们分别是用来主从复制（备份恢复）、故障恢复和事务回滚的。

前置：使用Linux