mysql独立表空间_MySQL三大日志：binlog、redolog、undolog全解析

概述

在 MySQL 数据库系统中，log扮演着至关重要的角色，其全称是二进制日志。它相当于数据库的“备忘录”，详尽地记录了所有DDL（数据定义语言）和DML（数据操作语言）的操作，包括创建、插入、更新以及删除等常见操作，每一个操作都被它逐一记录在案。

数据恢复方面具有显著功效，尤其是在数据库遭遇故障或数据丢失时，我们得以借助其功能恢复数据，从而保障数据的完整与统一。此外，在主从复制环境中，其作用尤为关键，从库能够通过读取主库的相应信息，确保数据同步，使主从库的数据始终保持同步状态。此外，通过深入分析，我们能够对数据库的操作记录进行审查，这有助于我们监视数据库的运行状况与性能表现。而且，采用增量备份的方式也是一个不错的选择，这种方法不仅能提升备份的效率，还能有效缩短备份所需的时间。

启用与配置

若要在MySQL数据库中激活该功能，首先需要在MySQL的配置文件中进行相应的参数调整，通常该文件为f或my.ini。完成参数设置后，需重启MySQL服务以确保更改生效。具体步骤包括：逗号，配置文件中调整参数，逗号，重启MySQL服务，逗号，确保更改生效。

首先，请打开 MySQL 的配置文件，通常它存放于 /etc/mysql/f 或 /etc/f 路径之中。然后，在文件中寻找或新增以下配置选项：，

[mysqld]
server-id=1
配置日志路径为/var/log/mysql/mysql-bin.log，并启用二进制日志功能。
binlog-format=row

每个参数都承载着其特定的意义和功能。例如，"-id" 作为 MySQL 实例的唯一标识，在主从复制机制中，主库与从库的 "-id" 必须保持不同，以确保能够精确地区分各个实例。而 "log-bin" 参数则负责确定二进制日志文件的存储位置及文件名的前缀。在上述配置中，该参数已被设置为特定值。

在默认情况下，日志文件位于/var/log/mysql目录下的mysql-bin.log，但在实际使用过程中，用户可以根据个人需求自行设定路径及文件名的前缀。此外，-参数用于指定日志的记录格式，其中常用的格式包括（语句模式）、ROW（行模式）以及MIXED（混合模式）。在此推荐使用ROW模式，因为它能够提供更为详尽的修改记录信息。

除了上述提到的基本配置之外，尚有若干其他配置参数，这些参数能够对系统的性能及行为进行更深入的优化。例如，其中一项参数用于设定单个文件的容量上限，若设定为“=100M”，则表示一旦文件容量达到100MB，系统便会自动生成新的文件。例如，该功能能够设定特定文件的失效期限，例如输入“=7”，这表示文件将在7天后自动删除，以此防止过多占用磁盘存储空间。此参数决定了在每次事务完成提交后，是否需要立刻将数据同步至硬盘。若将此值设为“1”，则每次事务提交后数据便会立即写入磁盘。此举虽能增强数据的安全性，然而却可能对系统性能产生一定影响。此外，您还可以指定需记录的数据库名称，比如使用“=”符号，那么系统仅会记录与该特定数据库相关的操作；相对地，使用“-”符号来指定，则表示将排除对该数据库的操作记录。

查看与管理

查阅相关文件，您会发现有具体的方法介绍。若需列出所有文件，请执行“mysql -uroot -p -e 'SHOW LOGS;'”这一命令，执行完毕后，系统将展示当前数据库中所有文件及其大小，展示形式与下方类似。

对任何未经授权的复制、传播或使用本公司的知识产权的行为，将严格禁止并采取必要的法律措施予以制止。
|Log_name |File_size |
+------------------+-----------+
该文件名为mysql-bin.000001，其大小为1073741824字节。
该记录位于mysql-bin.000002文件中，其偏移量为1073741824。
+------------------+-----------+

要是想查看某个 文件的具体内容，那就可以使用 “

运行“/var/log/mysql/mysql-bin.”这一指令（请注意，文件路径需根据具体情况进行设定），完成操作后，您便可以查看该文件中所记录的详细信息。

在执行文件清理任务时，我们通常可以通过配置相关参数，使系统自动执行这一过程。然而，若需手动进行清理，同样存在相应的指令可供使用。例如，若要查看当前的清理策略，可以输入“mysql -uroot -p -e 'SHOW LIKE '';'”这一命令，该命令将展示当前设置的清理策略详情。若需手动删除所有早于指定文件的记录，可执行“mysql -uroot -p -e 'PURGE LOGS TO 'mysql-bin.'；'”这一指令。以实例说明，若在执行此命令前，系统中存在名为mysql-bin.、mysql-bin.、mysql-bin.的文件，那么执行该命令后，将仅剩mysql-bin.这一个文件。若需删除特定时间点之前的记录，可以执行“mysql -uroot -p -e 'PURGE LOGS '2023-01-01 00:00:00''”这一指令，请注意，时间格式必须遵循YYYY-MM-DD HH:MM:SS的规范。

的使用场景数据恢复与备份

在数据恢复与备份的领域，它发挥着至关重要的作用。一旦数据库遭遇故障或不幸丢失数据，我们便可以利用它来恢复数据。例如，若数据库在某日清晨遭遇故障，我们可以依照以下步骤进行数据恢复：

首先，需暂停MySQL的运行，可以通过执行带有“-u root -p”参数的命令来完成这一操作。

在第二步中，我们需要对数据文件进行恢复操作，这一过程通常涉及从事先准备好的备份文件中提取数据文件。

第三步，使用 恢复数据，通过 “

使用命令“/var/log/mysql/mysql-bin.| mysql -u root -p”，即可将指定文件中的操作执行于数据库之中，进而完成数据的恢复工作。

数据库复制

在主从复制机制中，这种功能同样扮演着至关重要的角色。主库负责将所有操作详尽地记录下来，而随后从库则会通过读取这些记录，从而完成数据的同步。具体的配置步骤包括：

在主库这边，配置如下：

[mysqld]
server-id=1
log-bin=/var/log/mysql/mysql-bin.log
binlog-do-db=my_database

此处将“-id”设定为主库的独有标识，"log-bin"则明确了日志文件的存储地点，另外，“-do-db”选项则用于指定那些需要实现数据同步的数据库。

在从库这边，配置如下：

[mysqld]
server-id=2
log-slave-updates
read-only=1

在此处，将-id 设置为从库的唯一识别码，而"log-slave-"则表明从库会将接收到的相关记录存储于其自身的日志中，"read-only"标识着从库被配置为只读模式，严禁执行任何写操作。

完成配置后，首先需利用特定指令设定从库的主库资料，同时指明同步的起始点；随后，通过执行“START SLAVE;”指令来激活从库的复制功能，从而确保从库能够顺畅地与主库实现数据同步。

概念

在 MySQL 数据库中，重做日志扮演着至关重要的角色，它是确保数据持久性和完整性的核心，属于物理日志范畴。简言之，它主要负责记录数据页的物理变更信息。众所周知，MySQL 在执行数据增加、删除、修改等操作时，通常首先在内存中完成，一旦此时系统遭遇异常，例如突然断电或服务器宕机，内存中尚未持久化的数据便会消失无踪。这项技术应运而生，旨在解决这一问题；它能够记录对数据页的任何修改，并在恰当的时刻将这些修改同步至磁盘；即便遭遇突发状况，也能借助这些记录将数据恢复，从而确保数据不会因系统故障而丢失。

存储与构成

该数据存储包括两个主要部分，一是内存中的日志缓存，被称为重做日志，二是位于磁盘上的重做日志文件，亦即重做日志文件。

作为内存中的缓存区，redo log 首先会接收数据变更过程中产生的日志信息。在执行 SQL 语句对数据进行修改的过程中，这些变更内容会被先暂时存储在 redo log 中。

redo日志文件确实存储在磁盘之中，它是由若干个redo日志块构成的，而这些redo日志块的大小通常都是一致的，比如有些就是512KB的容量。此外，还有一个名为log group的概念，这实际上是由多个redo log file构成的逻辑集合。通常情况下，系统会默认配置两个redo log file，例如命名为xxx、yyy等，它们共同构成一个log group。这些文件相互协作，为数据的存储以及后续的磁盘写入等操作奠定了基础架构。

刷盘时机

从内存刷入磁盘可是有多种时机的哦。

首先，有个重要的参数

能够调整磁盘读写策略。这项设置拥有三个选项，每个选项都对应着不同的磁盘读写状态。当设置为0时，意味着每次事务完成时，redo log将保留在内存中，此模式下事务提交时不会自动执行写入磁盘的操作，而是由MySQL的后台线程每秒将缓存于redo log中的内容，通过调用write()函数写入操作系统的Page Cache，接着通过fsync()函数将数据持久化至磁盘，但若MySQL进程意外终止，则可能导致前一秒内所有事务数据丢失；当设置为1时，每次事务提交都会将redo log中的内容直接写入磁盘，即便MySQL异常重启，数据也不会丢失；而当设置为2时，每次事务提交仅将redo log中的内容写入文件，即写入操作系统的Page Cache，随后再通过fsync()函数将数据持久化至磁盘，相较于设置值为0的情况，这种做法安全性更高，只有当操作系统崩溃或系统断电时，前一秒的事务数据才可能丢失。

其次，一旦 redo log 记录的写入量超过其内存空间的一半，就会触发数据写入磁盘的操作。这主要是因为 redo log 是一种循环使用的内存结构，它会被不断重复利用。当其使用量达到一半时，就需要将内部的数据移至磁盘，以便释放出空间，以便继续接收新的日志记录。

此外，该系统的后台线程每秒钟都会将重做日志固定到磁盘上，确保数据的及时保存。

请注意，在进行操作的过程中，同样会触发涉及刷盘的操作，这样做主要是为了确保数据的一致性与可恢复性。

最终，在 MySQL 正常终止运行的过程中，系统还会将 redo log 中尚未写入磁盘的数据同步至磁盘，以此确保数据的完整性得到妥善保存。

概念

MySQL中存在一种特殊日志，它被称为回滚日志。在执行数据库事务操作的过程中，如果事务尚未完成提交，MySQL会预先将数据变更前的状态记录至日志文件。通过这种方式，一旦事务需要回滚，或者数据库遭遇崩溃等意外情况，我们便能够借助回滚日志来恢复数据，使其回到事务启动时的状态。在执行删除语句“从用户表中删除id为1的记录”时，系统会同步记录一条反向插入语句“向用户表(id字段)插入一条记录(id值为1)”，此操作旨在确保在事务回滚过程中，能够将数据恢复至原始状态。例如，在执行“将用户信息中的姓名修改为‘李四’，条件是用户ID等于1”（假设修改前用户姓名为‘张三’）这一更新操作时，系统会自动记录一条与之相反的“将用户信息中的姓名修改为‘张三’，条件是用户ID等于1”的撤销语句。若此修改过程中发生异常，可以通过日志记录进行回滚，以此确保事务处理的完整性。

作用

在 MySQL 数据库中有着两个非常重要的作用。

首先，确保事务的不可分割性，通过提供回滚机制。在执行数据变更的过程中，MySQL不仅会生成重做日志（redo log），同时还会记录下其他相关信息。若出现某些状况，例如发生失误或用户执行了不当指令，使得事务必须进行回滚，MySQL便会运用特定机制，将数据状态回溯至事务启动之初，以此保证事务内所有操作要么完全完成，要么完全撤销，从而满足事务的原子性原则。

其次，在存储引擎部分，我们实现了多版本并发控制（MVCC）机制。当某一行的数据被其他事务锁定时，我们能够通过该机制分析出该行数据的历史版本信息，从而使用户能够访问到当前事务操作之前的数据。这种方式，我们称之为“快照读”，在执行普通查询语句时，即可实现这一功能。此功能对于增强数据库的并发处理能力至关重要，它使得各类事务能够相对独立地访问数据，减少相互之间的干扰。

存储机制

该存储功能由特定的存储引擎负责执行，数据则被保存在相应的数据文件里。其存储方式采用了分段技术，其中回滚段构成了这一过程中的关键环节。

每个回滚段中包含 1024 个 undo log 。在 MySQL 5.5版本之前，系统仅能容纳一个，这意味着最多只能记录下1024次undo操作；然而，自MySQL 5.5版本起，系统支持128个，这些分别对应于resg slot0至resg，每个resg slot，也就是每个回滚段，内部由1024个undo构成，因此总共可以记录下128乘以1024次undo操作。

日志中不仅保存了数据变更前的历史资料，而且详细记载了行标识（RowID）、每次递增的事务ID以及回滚指针等相关信息。回滚指针在操作中扮演着至关重要的角色，比如在执行首次语句时，其回滚指针会变为空值（NULL），而在后续操作中，每次的回滚指针都将指向前一条记录，如此连续下去，便构成了一个回滚的记录链，这对于追踪记录的历史版本极为便利。

工作原理

在数据更新之前，MySQL 会预先创建日志文件。在事务完成提交后，这些日志并不会立刻被删除，因为后续可能需要进行回滚操作。执行回滚操作时，系统会从缓存中检索数据。日志的清除工作则由后台的 purge 线程负责处理。

以一个实例来阐述其运作流程，若事务A执行某项操作，且该事务尚未完成提交，系统会首先将相关数据备份至相应的undo区域，随后将undo区域的内容持久化至磁盘上的特定文件中，从而记录下未提交操作前的日志信息。紧接着，系统会将操作涉及的数据（例如表格数据）进行持久化保存至数据文件IBD中。若当前进行事务B的查询，将直接从undo缓存中提取信息，这是因为事务A尚未完成提交。若需对事务进行回滚，亦需首先从undo缓存中获取数据。

进一步简化地审视，整个通过利用该机制确保事务的原子性与持久性的过程可以描述为：设想存在两组数据，标记为A和B，它们最初的数值分别是1和2。事务启动后，首先将 A 的值从 1 记录至某个范围，随后将 A 的值更改为 3，紧接着将 B 的值从 2 记录至同一范围，并将 B 的值更新为 4。接着，将相关数据写入磁盘以实现数据的持久化，随后再次将数据写入磁盘以完成数据持久化的过程，最终完成事务的提交。之所以能够同时确保数据的原子性和持久性，是因为在进行数据更新操作之前，会进行记录，并且为了确保数据的持久性，在事务提交之前，数据必须被写入磁盘，而且这一步骤必须优先于数据被保存到磁盘上。一旦系统崩溃发生在数据及事务都完成持久化但提交动作之前，那么这些数据便保持完整，足以用于后续的回滚操作；相反，若系统崩溃在数据尚未写入磁盘时发生，磁盘中的数据将保留在事务启动时的原始状态。

相关参数

有几个和 相关的重要参数值得关注。

首先，我们需要关注的是 y 参数，该参数的作用在于设定日志文件的存放路径；它的默认值是 “./”。根据我们的具体存储计划和实际需求，我们可以对这一参数进行修改，以此来改变日志文件存放的具体位置。

还有参数存在，这些参数在不同版本间可能存在细微差别，它们与可支持的撤销日志数量等因素相关。例如，前面提到的回滚段数量等配置，这些因素在一定程度上会与该参数协同作用，共同管理相关资源的分配状况。

此外，ces 参数同样至关重要，它允许用户设定独立undo表空间的数量，其取值范围在0到128之间，而默认的设定为0。当参数设为0，即不启用独立的undo表空间，此时undo日志会被保存在特定文件中；相反，若设定一个合适的数值以启用独立的表空间，则可以在一定程度上更加灵活地处理存储管理以及性能优化等问题。然而，此参数只能在MySQL实例初始化阶段进行指定。一旦实例已创建，通常无法更改该参数。若在数据库配置文件中指定的数值超过了实例创建时设定的数量，数据库启动时将会失败，并会显示参数设置错误的信息。

合理地调整这些参数配置，将有助于我们更高效地管理并优化MySQL的使用效果，从而使它更有效地运作，并满足各种业务场景对事务回滚、数据完整性和性能等方面的需求。

三大日志的关联与协作

协作场景

在 MySQL 的实际运作中，这三类日志——即错误日志、慢查询日志和通用查询日志——相互协作，确保了数据库操作的正确性、数据的完整性以及各种功能的顺畅执行。

在执行类似“user SET age = 25 WHERE id = 1;”的数据更新指令时，存储引擎层将首先介入处理。在进行数据修改之前，我们首先会将现有的数据状况存档，从而创建一个可供回溯的历史版本。这相当于记录下原始id为1的用户年龄信息，以便在必要时能够恢复到这一状态。

随后，将此次数据变更所引发的物理变化信息录入其中，然而此时该信息处于特定状态，比如记录了数据页中关于用户年龄变更的物理变动详情。此外，这一记录并非直接写入磁盘，而是首先临时存储在重做日志（redo log）中，其写入磁盘的具体时间受到

参数设置不同，其操作结果亦异：参数值为1，每笔事务完成提交后，redo log中的记录即刻被写入磁盘；若参数为0，后台线程将每秒处理一次写入磁盘的操作；而当参数为2，数据首先被写入操作系统的Page Cache，随后再进行磁盘持久化。

随后，MySQL的数据库层将生成一条与该更新操作相对应的日志，以记录该语句在逻辑上的更新细节，例如记录了一条将ID为1的用户年龄修改为25的操作。这条日志首先会被写入缓存中，接着根据配置的参数来决定何时将数据同步到磁盘。例如，当参数设置为1时，在提交事务的瞬间，数据便会立即刷新至磁盘。

最终，在事务正式进入提交阶段，系统会将该事务的当前状态更改为另一种状态，唯有如此，整个事务的提交过程才可视为彻底完成。如果在执行过程中遭遇突发状况，例如数据库意外崩溃，当系统重启并开始恢复流程时，MySQL会首先对特定状态进行检测；若检测到该状态表明事务已成功完成，则会认定事务执行无误；若发现处于另一种状态，系统将检查相应事务的完整性；若完整性得到保证，则会对尚未提交的事务执行提交操作；反之，若完整性受损，系统将回滚该事务，从而确保数据的一致性与持久性。

在考察事务回滚的具体情况时，我们设想在完成一系列更新指令之后，因某些特定因素，执行了相应的命令以实现事务的回滚。此时，将运用先前所记录的信息进行数据回溯，将数据恢复至事务启动之初的状态，例如，之前所修改的用户信息等都将恢复原状。在此回滚过程中，涉及到的操作和流程将不再继续执行，如刷盘等，确保数据能够准确无误地回滚至先前版本。

在主从复制架构中，当主库执行各类操作动作时，它将同步生成并记录相应的日志信息。主库在完成操作记录后，从库会通过读取主库的相关记录以实现数据同步。在此过程中，从库在接收到数据的同时，也会进行自身日志的记录以及数据的更新操作。这些操作同样依赖于相似的日志协作机制，以确保数据的准确同步并维持一致性。若出现数据不一致等问题，相关日志也可用于问题的排查与恢复。

对比总结

下面从多个角度对 、、 这三大日志进行对比总结：

通过这样的对比总结，能更清晰地区分这三大日志的不同特点