简介

InnoDB存储引擎是MySQL中一种流行的存储引擎，它提供了一系列特性，包括高性能、高可靠性和事务支持。InnoDB使用redo日志作为其持久性和一致性机制的关键组成部分。本文将深入探讨InnoDB redo日志的类型、表空间ID、页号和具体内容，并解释它们在确保数据库安全和稳定方面的作用。

Redo日志类型

InnoDB为redo日志设计了50多种不同的类型。这些类型记录了不同的操作，包括插入、更新、删除等。通过记录不同类型的操作，redo日志可以准确地恢复数据库的状态，确保数据的一致性。以下是redo日志中一些最常见的类型： ROW_INS：记录插入操作 ROW_UPD：记录更新操作 ROW_DEL：记录删除操作 PURGE_LOG：记录日志清理操作 COMMIT：记录事务提交操作 ROLLBACK：记录事务回滚操作

表空间ID

在InnoDB中，数据库被分为多个表空间，每个表空间存储了一组相关的数据。redo日志中的表空间ID指示了该日志记录所属的表空间。通过表空间ID，系统可以定位到正确的表空间，以便恢复数据时使用。

页号

页号是redo日志中的另一个重要信息。在InnoDB中，数据被组织成多个页，每个页的大小通常为16KB。页号指示了该日志记录所操作的页的位置。通过页号，系统可以找到正确的页，并将日志记录的操作应用到该页上。

具体内容

redo日志中的每条记录都包含了具体的操作内容。这些内容可以是对数据的插入、更新或删除操作。通过记录具体的操作内容，系统可以在恢复时准确地重做这些操作，使得数据库的状态与崩溃前保持一致。

总结

InnoDB redo日志是确保数据库持久性和一致性的一项重要机制。每条redo日志记录都包含了类型、表空间ID、页号以及具体内容等重要信息。通过这些信息，系统可以在恢复时准确地重做操作，保证数据库的数据不丢失且与崩溃前保持一致。

对数据库维护的重要性

在实际的数据库运维中，了解redo日志的原理和作用对于确保数据库的安全和稳定非常重要。管理员需要定期备份和管理redo日志，以便在系统崩溃或数据损坏时能够快速恢复。同时，通过合理配置redo日志大小和写入策略，可以提高数据库的性能和稳定性。

结论

redo日志是InnoDB存储引擎中的一项重要机制，它记录了数据库中的操作，并确保数据的持久性和一致性。了解redo日志的类型、表空间ID、页号以及具体内容，可以帮助我们更好地理解数据库的运行机制，并采取相应的措施来保证数据的安全和稳定。

---

在数据库中，REDO操作和UNDO操纵个表示什么含义？

一个是撤销你之前的行为，另一个则是恢复操作--redo00 – Undo LogUndo Log 是为了实现事务的原子性，在MySQL数据库InnoDB存储引擎中，还用Undo Log来实现多版本并发控制(简称：MVCC)。 - 事务的原子性(Atomicity)事务中的所有操作，要么全部完成，要么不做任何操作，不能只做部分操作。 如果在执行的过程中发生了错误，要回滚(Rollback)到事务开始前的状态，就像这个事务从来没有执行过。 - 原理Undo Log的原理很简单，为了满足事务的原子性，在操作任何数据之前，首先将数据备份到一个地方（这个存储数据备份的地方称为Undo Log）。 然后进行数据的修改。 如果出现了错误或者用户执行了ROLLBACK语句，系统可以利用Undo Log中的备份将数据恢复到事务开始之前的状态。 除了可以保证事务的原子性，Undo Log也可以用来辅助完成事务的持久化。 - 事务的持久性(Durability)事务一旦完成，该事务对数据库所做的所有修改都会持久的保存到数据库中。 不能因为错误/重启/宕机而丢失已经COMMIT的数据。 为了保证持久性，数据库系统需要将修改后的数据完全的记录到持久的存储上。 - 用Undo Log实现原子性和持久化的事务的简化过程假设有A、B两个数据，值分别为1,2。 A.事务开始.B.记录A=1到undo log的内存buffer.C.在内存中修改A=3.D.记录B=2到undo log的内存buffer.E.在内存中修改B=4.F.将undo log的buffer写到磁盘。 G.将内存中修改后的数据写到磁盘。 H.事务提交这里有一个前提条件：‘数据都是先读到内存中，然后修改内存中的数据，最后将数据写回磁盘’。 以上过程之所以能同时保证原子性和持久化，是因为以下特点：A. 更新数据前记录Undo log。 B. 为了保证持久性，必须将数据在事务提交前写到磁盘。 只要事务成功提交，数据必然已经持久化。 C. Undo log必须先于数据持久化到磁盘。 如果在G,H之间系统崩溃，undo log是完整的，可以用来回滚事务。 D. 如果在A-F之间系统崩溃,因为数据没有持久化到磁盘。 所以磁盘上的数据还是保持在事务开始前的状态。 缺陷：每个事务提交前将数据和Undo Log写入磁盘，这样会导致大量的磁盘IO，因此性能很低。 如果能够将数据缓存一段时间，就能减少IO提高性能。 但是这样就会丧失事务的持久性。 因此引入了另外一种机制来实现持久化，即Redo Log.01 – Redo Log- 原理和Undo Log相反，Redo Log记录的是新数据的备份。 在事务提交时，只要将Redo Log持久化即可，不需要将数据持久化。 当系统崩溃时，虽然数据没有持久化，但是Redo Log已经持久化。 系统可以根据Redo Log的内容，将所有数据恢复到最新的状态。 - Undo + Redo事务的简化过程假设有A、B两个数据，值分别为1,2.A.事务开始.B.记录A=1到undo log的内存buffer.C.内存中修改A=3.D.记录A=3到redo log的内存buffer.E.记录B=2到undo log的内存buffer.F..内存中修改B=4.G.记录B=4到redo log的内存buffer.H.将redo log的内存buffer写入磁盘。 I.事务提交- Undo + Redo事务的特点A. 为了保证持久性，必须在事务提交时将Redo Log持久化。 B. 数据不需要在事务提交前写入磁盘，而是缓存在内存中。 C. Redo Log 保证事务的持久性。 D. Undo Log 保证事务的原子性。 E. 有一个隐含的特点，数据必须要晚于redo log写入持久存储。 这是因为Recovery要依赖redo log. 如果redo log丢失了，系统需要保持事务的数据也没有被更新。 - IO性能Undo + Redo的设计主要考虑的是提升IO性能。 虽说通过缓存数据，减少了写数据的IO. 但是却引入了新的IO，即写Redo Log的IO。 如果Redo Log的IO性能不好，就不能起到提高性能的目的。 为了保证Redo Log能够有比较好的IO性能，InnoDB 的 Redo Log的设计有以下几个特点：A. 尽量保持Redo Log存储在一段连续的空间上。 以顺序追加的方式记录Redo Log,通过顺序IO来改善性能。 因此在系统第一次启动时就会将日志文件的空间完全分配，从而保证Redo Log文件在存储上的空间有更好的连续性。 B. 批量写入日志。 日志并不是直接写入文件，而是先写入redo log buffer.当需要将日志刷新到磁盘时 (如事务提交),才将许多日志一起写入磁盘，这样可以减少IO次数。 C. 并发的事务共享Redo Log的存储空间，它们的Redo Log按语句的执行顺序，依次交替的记录在一起，以减少Redo Log的IO次数。 例如,Redo Log中的记录内容可能是这样的：记录1: <trx1, insert …>记录2: <trx2, update …>记录3: <trx1, delete …>记录4: <trx3, update …>记录5: <trx2, insert …>D. 因为C的原因,当一个事务将Redo Log写入磁盘时，也会将其他未提交的事务的日志写入磁盘。 E. Redo Log上只进行顺序追加的操作，当一个事务需要回滚时，它的Redo Log记录也不会从Redo Log中删除掉。 InnoDB的做法时将回滚操作也记入Redo Log(具体做法看下一节).

一文详解-MySQL 事务和锁

当多个用户访问同一份数据时，一个用户在更改数据的过程中，可能有其他用户同时发起更改请求，为保证数据库记录的更新从一个一致性状态变为另外一个一致性状态，使用事务处理是非常必要的，事务具有以下四个特性： MySQL 提供了多种事务型存储引擎，如 InnoDB 和 BDB 等，而 MyISAM 不支持事务。 为了支持事务，InnoDB 存储引擎引入了与事务处理相关的 REDO 日志和 UNDO 日志，同时事务依赖于 MySQL 提供的锁机制 事务执行时需要将执行的事务日志写入日志文件，对应的文件为 REDO 日志。 当每条 SQL 进行数据更新操作时，首先将 REDO 日志写进日志缓冲区。 当客户端执行 COMMIT 命令提交时，日志缓冲区的内容将被刷新到磁盘，日志缓冲区的刷新方式或者时间间隔可以通过参数 innodb_flush_log_at_trx_commit 控制 REDO 日志对应磁盘上的 ib_logifleN 文件，该文件默认为 5MB，建议设置为 512MB，以便容纳较大的事务。 MySQL 崩溃恢复时会重新执行 REDO 日志的记录，恢复最新数据，保证已提交事务的持久性 与 REDO 日志相反，UNDO 日志主要用于事务异常时的数据回滚，具体内容就是记录数据被修改前的信息到 UNDO 缓冲区，然后在合适的时间将内容刷新到磁盘 假如由于系统错误或者 rollback 操作而导致事务回滚，可以根据 undo 日志回滚到没修改前的状态，保证未提交事务的原子性 与 REDO 日志不同的是，磁盘上不存在单独的 UNDO 日志文件，所有的 UNDO 日志均存在表空间对应的 数据文件中，即使 MySQL 服务启动了独立表空间 在 MySQL 中，可以使用 BEGIN 开始事务，使用 COMMIT 结束事务，中间可以使用 ROLLBACK 回滚事务。 MySQL 通过 SET AUTOCOMMIT、START TRANSACTION、COMMIT 和 ROLLBACK 等语句支持本地事务 MySQL 定义了四种隔离级别，指定事务中哪些数据改变其他事务可见、哪些数据该表其他事务不可见。 低级别的隔离级别可以支持更高的并发处理，同时占用的系统资源更少 InnoDB 系统级事务隔离级别可以使用以下语句设置： 查看系统级事务隔离级别： InnoDB 会话级事务隔离级别可以使用以下语句设置： 查看会话级事务隔离级别： 在该隔离级别，所有事务都可以看到其他未提交事务的执行结果。 读取未提交的数据称为脏读（Dirty Read），即是：首先开启 A 和 B 两个事务，在 B 事务更新但未提交之前，A 事务读取到了更新后的数据，但由于 B 事务回滚，导致 A 事务出现了脏读现象 所有事务只能看见已经提交事务所做的改变，此级别可以解决脏读，但也会导致不可重复读（Nonrepeatable Read）：首先开启 A 和 B 两个事务，A事务读取了 B 事务的数据，在 B 事务更新并提交后，A 事务又读取到了更新后的数据，此时就出现了同一 A 事务中的查询出现了不同的查询结果 MySQL 默认的事务隔离级别，能确保同一事务的多个实例在并发读取数据时看到同样的数据行，理论上会导致一个问题，幻读（Phontom Read）。 例如，第一个事务对一个表中的数据做了修改，这种修改会涉及表中的全部数据行，同时第二个事务也修改这个表中的数据，这次的修改是向表中插入一行新数据，此时就会发生操作第一个事务的用户发现表中还有没有修改的数据行 InnoDB 通过多版本并发控制机制（MVCC）解决了该问题：InnoDB 通过为每个数据行增加两个隐含值的方式来实现，这两个隐含值记录了行的创建时间、过期时间以及每一行存储时间发生时的系统版本号，每个查询根据事务的版本号来查询结果 通过强制事务排序，使其不可能相互冲突，从而解决幻读问题。 简而言之，就是在每个读的数据行上加上共享锁实现，这个级别会导致大量的超时现象和锁竞争，一般不推荐使用 为了解决数据库并发控制问题，如走到同一时刻客户端对同一张表做更新或者查询操作，需要对并发操作进行控制，因此产生了锁 共享锁的粒度是行或者元组（多个行），一个事务获取了共享锁以后，可以对锁定范围内的数据执行读操作 排他锁的粒度与共享锁相同，一个事务获取排他锁以后，可以对锁定范围内的数据执行写操作 有两个事务 A 和 B，如果事务 A 获取了一个元组的共享锁，事务 B 还可以立即获取这个元组的共享锁，但不能获取这个元组的排他锁，必须等到事务 A 释放共享锁之后。 如果事务 A 获取了一个元组的排他锁，事务 B 不能立即获取这个元组的共享锁，也不能立即获取这个元组的排他锁，必须等到 A 释放排他锁之后 意向锁是一种表锁，锁定的粒度是整张表，分为意向共享锁和意向排他锁。 意向共享锁表示一个事务有意对数据上共享锁或者排他锁。 有意表示事务想执行操作但还没真正执行 锁的粒度主要分为表锁和行锁 表锁的开销最小，同时允许的并发量也是最小。 MyISAM 存储引擎使用该锁机制。 当要写入数据时，整个表记录被锁，此时其他读/写动作一律等待。 一些特定的动作，如 ALTER TABLE 执行时使用的也是表锁 行锁可以支持最大的并发，InnoDB 存储引擎使用该锁机制。 如果要支持并发读/写，建议采用 InnoDB 存储引擎