日志

错误日志(err log)

• 记录了运行过程中遇到的所有严重的错误信息,以及 MySQL每次启动和关闭的详细信息。

二进制日志(bin log)

• 默认是关闭的，需要通过配置：log-bin=mysql-bin进行开启。其中mysql-bin是binlog日志文件的basename，binlog日志文件的名称：mysql-bin-000001.log
• binlog用于实现mysql主从复制以及数据恢复。
• 记录了所有的操作语句

通用查询日志(general query log)

• 默认情况下通用查询日志是关闭的
• 由于通用查询日志会记录用户的所有操作，其中还包含增删查改等信息，在并发操作大的环境下会产生大量的信息从而导致不必要的磁盘IO，会影响mysql的性能的。如若不是为了调试数据库的目的建议不要开启查询日志。

慢查询日志(slow query log)

• 默认是关闭的。需要通过设置：slow_query_log=ON进行开启。
• 记录执行时间超过long_query_time秒的所有查询，便于收集查询时间比较长的SQL语句

事务日志

• 

redolog

• redo log是重做日志，提供前滚操作。有了redo log，当数据库发生宕机重启后，可通过redo log将未落盘的数据恢复，即保证已经提交的事务记录不会丢失
  • redo是固定大小的，redo log是innodb层产生的，只记录该存储引擎中表的修改
  • 在概念上，innodb通过force log at commit机制实现事务的持久性，即在事务提交的时候，必须先将该事务的所有事务日志写入到磁盘上的redo log file和undo log file中进行持久化。
  • 为了确保每次日志都能写入到事务日志文件中，在每次将log buffer中的日志写入日志文件的过程中都会调用一次操作系统的fsync操作(即fsync()系统调用)。因为MariaDB/MySQL是工作在用户空间的，MariaDB/MySQL的log buffer处于用户空间的内存中。要写入到磁盘上的log file中(redo:ib_logfileN文件,undo:share tablespace或.ibd文件)，中间还要经过操作系统内核空间的os buffer，调用fsync()的作用就是将OS buffer中的日志刷到磁盘上的log file中
• 物理逻辑日志：记录的是数据页（Page）级别的物理修改（如“在Page X的Offset Y写入数据Z”），但它不是纯粹的物理字节变化（那样太底层且体积大），也不是纯粹的逻辑SQL语句（那样恢复慢）。它是物理位置+逻辑操作的结合，效率很高

undolog

• undo log是回滚日志，提供回滚操作。
  • 为了修改某行数据，InnoDB 会先将该行数据的旧版本拷贝到 undo log 中
  • Undo log 记录本身的产生也会产生 redo log！因为 undo log 需要持久化，也需要 WAL 保护
  • 如果事务提交：该事务的 undo log 不会立即删除！它需要为 MVCC 服务。只有在没有任何活动事务（或快照读）还需要访问该 undo log 记录所代表的历史版本时，该记录才会被后台的 purge 线程清理掉
  • 核心作用
    • 事务回滚：
      记录事务修改前的旧值，用于回滚未提交的事务（保证原子性）。
    • MVCC支持：
      为其他事务提供旧版本数据，实现非锁定读（读不阻塞写，写不阻塞读）。

• 特性	redo log	undo log
  核心目的	保证事务的持久性（Durability）	支持事务的原子性（Atomicity）和多版本并发控制（MVCC）
  日志类型	物理日志（记录数据页的修改）	逻辑日志（记录逆向操作，如SQL的反向逻辑）
  写入时机	事务进行中实时写入	事务修改数据前记录旧值
  生命周期	事务提交后即可覆盖（循环写入）	保留到没有事务依赖旧版本数据（可能长期存在）
  恢复作用	崩溃恢复时重放未落盘的数据（前滚）	回滚未提交事务，或提供MVCC的旧版本数据
  存储方式	顺序写入（高效）	存储在回滚段（undo segments）中

WAL

• WAL（Write-Ahead Logging，预写式日志）机制是InnoDB存储引擎实现事务持久性（Durability）和崩溃恢复（Crash Recovery）的核心技术
• 在将数据的修改写入磁盘上的数据文件之前，必须先将这些修改记录到持久化的日志文件中。

核心原理

• 先写缓存，在刷日志，最后写数据
  • 当需要修改数据库中的数据（插入、更新、删除）时，InnoDB不会立即将这些修改写入磁盘上的实际数据文件（.ibd文件）。
  • 它首先会将描述这些修改的日志记录写入内存中的 重做日志缓冲区（Redo Log Buffer）。
  • 然后，在适当的时机（通常是事务提交时），将这些缓冲区的日志记录顺序地、批量地写入磁盘上的 重做日志文件（Redo Log File）（通常是ib_logfile0和ib_logfile1）。
  • 只有确保描述数据修改的日志记录已经安全地、持久化地写入了磁盘上的重做日志文件后，InnoDB才会在后台线程中，选择合适的时间点将内存中修改过的数据页（脏页， Dirty Page）异步地刷新（Flush）到磁盘上的数据文件中。
• 日志先行于数据
  • 这个“写日志”操作必须在“写数据文件”操作之前完成并持久化。这是保证崩溃恢复能正常工作的关键前提。