在MySQL的世界里，日志不仅仅是记录系统活动的简单工具，它们更是确保数据一致性和可靠性、优化性能、以及辅助问题诊断的关键组件。本文将介绍MySQL日志体系的精髓，从核心的日志类型到它们各自的作用、工作原理及相互间的协作机制，为你揭示MySQL背后复杂而精妙的设计。

1 核心日志

1.1 binlog（查询日志）

binlog全称为binary log，是MySQL Server层实现的一种逻辑日志，记录了所有更改数据库数据的SQL语句或数据变更事件。它不依赖于特定的存储引擎，所有引擎均可使用，主要用于数据复制（如主从复制）、数据恢复及审计等功能，支持追加写入模式，不会循环覆盖旧日志，保证了数据的长期可追溯性。

1.1.1 binlog启用

MySQL5.7 版本中，binlog默认是关闭的，8.0版本默认是打开的。打开binlog功能，需要修改配置文件my.ini（windows）或my.cnf（linux），然后重启数据库：

[mysqld]
# log-bin设置binlog的存放位置，可以是绝对路径，也可以是相对路径，这里写的相对路径，则binlog文件默认会放在data数据目录下
log-bin=mysql-binlog
# Server Id是数据库服务器id，随便写一个数都可以，这个id用来在mysql集群环境中标记唯一mysql服务器，集群环境中每台mysql服务器的id不能一样，不加启动会报错
server-id=1
# 其他配置
binlog_format = MIXED # 日志文件格式，可以选择STATEMENT、ROW或MIXED
expire_logs_days = 15 # 执行自动删除距离当前15天以前的binlog日志文件的天数， 默认为0， 表示不自动删除
max_binlog_size = 200M # 单个binlog日志文件的大小限制，默认为 1GB

其中binlog_format设置binlog日志的记录格式支持三种格式类型：

STATEMENT：基于SQL语句的复制，每一条会修改数据的sql都会记录到master机器的bin-log中，这种方式日志量小，节约IO开销，提高性能，但是对于一些执行过程中才能确定结果的函数，比如UUID()、SYSDATE()等函数如果随sql同步到slave机器去执行，则结果跟master机器执行的不一样。
ROW：基于行的复制，日志中会记录成每一行数据被修改的形式，然后在slave端再对相同的数据进行修改记录下每一行数据修改的细节，可以解决函数、存储过程等在slave机器的复制问题，但这种方式日志量较大，性能不如Statement。举个例子，假设update语句更新10行数据，Statement方式就记录这条update语句，Row方式会记录被修改的10行数据。
MIXED：混合模式复制，实际就是前两种模式的结合，在Mixed模式下，MySQL会根据执行的每一条具体的sql语句来区分对待记录的日志形式，如果sql里有函数或一些在执行时才知道结果的情况，会选择Row，其它情况选择Statement，推荐使用。

1.1.2 binlog生成

以下情形binlog日志文件会进行生成：

服务器启动或重新启动
服务器刷新日志，执行命令flush logs
日志文件大小达到 max_binlog_size 值，默认值为 1GB

1.1.3 常用操作

1.1.3.1 查看所有binlog

使用show binary logs命令来查看系统中所有可用的binlog文件列表。这个命令会显示每个binlog文件的名称和它们各自的位置（即文件结束时的位置）。这有助于了解当前有哪些binlog文件存在，以及它们的状态。

show binary logs;

查看所有binlog文件

1.1.3.2 查看当前binlog

使用show master status命令可以获取当前正在写入的binlog文件的信息，包括文件名、文件位置（binlog文件中最后一个事件的结束位置）、服务器的全局事务ID（如果有GTID模式启用）和其他相关信息。

show master status

查看当前binlog文件

1.1.3.3 读取binlog

读取binlog的内容，需要使用mysqlbinlog工具，用于解析和展示binlog文件中的事件。

# 查看bin-log二进制文件（命令行方式，不用登录mysql）
mysqlbinlog --no-defaults -v --base64-output=decode-rows {path}/mysql-binlog.000001

如果想按时间或位置筛选日志内容，可以使用start-datetime、stop-datetime、start-position和stop-position选项。

mysqlbinlog --no-defaults -v --base64-output=decode-rows {path}/mysql-binlog.000001 start-datetime="2024-01-21 00:00:00" stop-datetime="2024-02-01 00:00:00" start-position="5000" stop-position="20000"

1.1.3.4 删除binlog

在某些情况下，可能需要清理旧的binlog文件以释放磁盘空间。可以使用以下方法来删除binlog文件：

使用PURGE语句删除指定日期前的所有日志文件，或者删除到某个文件为止的所有日志文件。

# 删除指定日志文件之前的所有日志文件，下面这个是删除6之前的所有日志文件，当前这个文件不删除
purge master logs to 'mysql-binlog.000002';
# 删除指定日期前的日志索引中binlog日志文件
purge master logs before '2024-01-21 14:00:00';

使用RESET MASTER命令会清除所有binlog文件和binlog索引文件，这通常在重置整个复制环境时使用。

# 删除当前的binlog文件
reset master;

1.1.4 关键参数

log_bin：binlog日志是否打开状态，MySQL5.7 版本中binlog默认是关闭的，8.0版本默认是打开的。
log_bin_basename：是binlog日志的基本文件名，后面会追加标识来表示每一个文件，binlog日志文件会滚动增加
log_bin_index：指定的是binlog文件的索引文件，这个文件管理了所有的binlog文件的目录。
sql_log_bin：sql语句是否写入binlog文件，ON代表需要写入，OFF代表不需要写入。如果想在主库上执行一些操作，但不复制到slave库上，可以通过修改参数sql_log_bin来实现。比如说，模拟主从同步复制异常。
sync_binlog：这个参数控制redo log的写入策略，它有三种可能取值：
- 0：表示每次提交事务都只 write 到page cache，由系统自行判断什么时候执行 fsync 写入磁盘。虽然性能得到提升，但是机器宕机，page cache里面的 binlog 会丢失。
- 1：表示每次提交事务都会执行 fsync 写入磁盘，这种方式最安全。
- N（N>1）：表示每次提交事务都write 到page cache，但累积N个事务后才 fsync 写入磁盘，这种如果机器宕可能会丢失N个事务的binlog。

1.1.5 应用场景

1.1.5.1 恢复数据

用binlog日志文件恢复数据其实就是回放执行之前记录在binlog文件里的sql，举一个数据恢复的例子

-- 先执行刷新日志的命令生成一个新的binlog文件
flush logs;
-- 执行两条插入语句
INSERT INTO `test`.`account` (`id`, `name`, `balance`) VALUES ('4', 'wumin', '444');
INSERT INTO `test`.`account` (`id`, `name`, `balance`) VALUES ('5', 'liuzi', '555');
-- 假设现在误操作执行了一条删除语句把刚新增的两条数据删掉了
delete from account where id > 3;

确定日志文件：查找当前binlog文件show master status

查看binlog状态

确定恢复点：查看binlog文件找到两条插入数据的sql，每条sql的上下都有BEGIN和COMMIT，找到第一条sql BEGIN前面的文件位置标识 at 235，再找到第二条sql COMMIT后面的文件位置标识 at 752，

# at 235
#240709 20:50:41 server id 1  end_log_pos 310 CRC32 0x8c6671a0  Query   thread_id=8     exec_time=0     error_code=0
SET TIMESTAMP=1720529441/*!*/;
SET @@session.pseudo_thread_id=8/*!*/;
SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;
SET @@session.sql_mode=1075838976/*!*/;
SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;
/*!\C utf8mb4 *//*!*/;
SET @@session.character_set_client=255,@@session.collation_connection=255,@@session.collation_server=255/*!*/;
SET @@session.lc_time_names=0/*!*/;
SET @@session.collation_database=DEFAULT/*!*/;
/*!80011 SET @@session.default_collation_for_utf8mb4=255*//*!*/;
BEGIN
/*!*/;
# at 310
#240709 20:50:41 server id 1  end_log_pos 372 CRC32 0x072c210d  Table_map: `test`.`account` mapped to number 83
# at 372
#240709 20:50:41 server id 1  end_log_pos 423 CRC32 0x6d68521a  Write_rows: table id 83 flags: STMT_END_F
### INSERT INTO `test`.`account`
### SET
###   @1=4
###   @2='wumin'
###   @3=444
# at 423
#240709 20:50:41 server id 1  end_log_pos 454 CRC32 0xff66f214  Xid = 81
COMMIT/*!*/;
# at 454
#240709 20:50:41 server id 1  end_log_pos 533 CRC32 0x9258ce16  Anonymous_GTID  last_committed=1        sequence_number=2       rbr_only=yes    original_committed_timestamp=1720529441357189      immediate_commit_timestamp=1720529441357189     transaction_length=298
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720529441357189 (2024-07-09 20:50:41.357189 中国标准时间)
# immediate_commit_timestamp=1720529441357189 (2024-07-09 20:50:41.357189 中国标准时间)
/*!80001 SET @@session.original_commit_timestamp=1720529441357189*//*!*/;
/*!80014 SET @@session.original_server_version=80027*//*!*/;
/*!80014 SET @@session.immediate_server_version=80027*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 533
#240709 20:50:41 server id 1  end_log_pos 608 CRC32 0xb1067808  Query   thread_id=8     exec_time=0     error_code=0
SET TIMESTAMP=1720529441/*!*/;
BEGIN
/*!*/;
# at 608
#240709 20:50:41 server id 1  end_log_pos 670 CRC32 0x7850b940  Table_map: `test`.`account` mapped to number 83
# at 670
#240709 20:50:41 server id 1  end_log_pos 721 CRC32 0xe888733a  Write_rows: table id 83 flags: STMT_END_F
### INSERT INTO `test`.`account`
### SET
###   @1=5
###   @2='liuzi'
###   @3=555
# at 721
#240709 20:50:41 server id 1  end_log_pos 752 CRC32 0x9f37963b  Xid = 82
COMMIT/*!*/;
# at 752
#240709 20:50:41 server id 1  end_log_pos 831 CRC32 0x52ecfda5  Anonymous_GTID  last_committed=2        sequence_number=3       rbr_only=yes    original_committed_timestamp=1720529441361220      immediate_commit_timestamp=1720529441361220     transaction_length=314
/*!50718 SET TRANSACTION ISOLATION LEVEL READ COMMITTED*//*!*/;
# original_commit_timestamp=1720529441361220 (2024-07-09 20:50:41.361220 中国标准时间)
# immediate_commit_timestamp=1720529441361220 (2024-07-09 20:50:41.361220 中国标准时间)
/*!80001 SET @@session.original_commit_timestamp=1720529441361220*//*!*/;
/*!80014 SET @@session.original_server_version=80027*//*!*/;
/*!80014 SET @@session.immediate_server_version=80027*//*!*/;
SET @@SESSION.GTID_NEXT= 'ANONYMOUS'/*!*/;
# at 831
#240709 20:50:41 server id 1  end_log_pos 906 CRC32 0xe35bc7d6  Query   thread_id=8     exec_time=0     error_code=0
SET TIMESTAMP=1720529441/*!*/;
BEGIN
/*!*/;
# at 906
#240709 20:50:41 server id 1  end_log_pos 968 CRC32 0xf310527e  Table_map: `test`.`account` mapped to number 83
# at 968
#240709 20:50:41 server id 1  end_log_pos 1035 CRC32 0x326ab5e0         Delete_rows: table id 83 flags: STMT_END_F
### DELETE FROM `test`.`account`
### WHERE
###   @1=4
###   @2='wumin'
###   @3=444
### DELETE FROM `test`.`account`
### WHERE
###   @1=5
###   @2='liuzi'
###   @3=555
# at 1035
#240709 20:50:41 server id 1  end_log_pos 1066 CRC32 0x8537b79c         Xid = 83
COMMIT/*!*/;
SET @@SESSION.GTID_NEXT= 'AUTOMATIC' /* added by mysqlbinlog */ /*!*/;
DELIMITER ;

恢复数据：使用mysqlbinlog工具执行如下命令来恢复数据

mysqlbinlog --no-defaults --start-position=235 --stop-position=752 --database=test .\mysql-bin.000006 | mysql -u root -p

1.1.5.2 备份数据库

一般推荐的是每天（在凌晨后）做一次全量数据库备份，那么恢复数据库可以用最近的一次全量备份再加上备份时间点之后的binlog来恢复数据。数据库一般可以用mysqldump 命令工具。

mysqldump -u root 数据库名>备份文件名;   #备份整个数据库
mysqldump -u root 数据库名 表名字>备份文件名;  #备份整个表
mysql -u root test < 备份文件名 #恢复整个数据库，test为数据库名称，需要自己先建一个数据库test

1.2 redo log（重做日志）

redo log（重做日志）与binlog都服务于数据保护，但它们各有侧重。redo log保证事务安全，是InnoDB存储引擎负责在系统崩溃后恢复未完成的事务，确保事务的持久性（ACID中的D）。而binlog支持复制和备份。

1.2.1 日志结构

redo log以固定大小的文件形式存在，这些文件是循环使用的。当一个文件写满后，InnoDB会切换到下一个文件继续写入，直到所有文件都被写满，然后回到第一个文件重新开始。通过write pos（当前写入点）和check point（擦除点）的动态调整，保证了redo log的有效利用。

redo log工作机制|500

1.2.2 工作原理

MySQL InnoDB存储引擎通过结合WAL（Write-Ahead Logging）和两阶段提交（Two-Phase Commit, 2PC）来确保事务的持久性和一致性。

预写式日志：在数据页被修改并写入数据文件之前，InnoDB会先将修改信息写入redo log中并标记为prepare，记录下XID。
事务提交：在事务提交阶段，事务细节写入binlog，InnoDB会在redo log中标记事务为commit，只有当这些redo log记录被成功写入（通常是写入磁盘），事务才被视为提交成功。
崩溃恢复：binlog 写完，redo log 还没 commit前发生 crash的情况下，系统检查redo log，若有commit标记则直接提交事务；若仅发现prepare标记但binlog完整，则提交事务；如果binlog不完整，则回滚事务。XID用于redo log与binlog之间的关联匹配。

1.2.3 关键参数

innodb_log_buffer_size：设置redo log buffer大小参数，默认16M ，最大值是4096M，最小值为1M。
innodb_log_group_home_dir：设置redo log文件存储位置参数，默认值为"./"，即innodb数据文件存储位置，其中的 ib_logfile0 和 ib_logfile1 即为redo log文件。
innodb_log_files_in_group：设置redo log文件的个数，命名方式如：ib_logfile0，iblogfile1....iblogfileN。默认2个，最大100个。
innodb_log_file_size：设置单个redo log文件大小，默认值为48M，最大值为512G。（注意最大值指的是整个 redo log系列文件之和，即innodb_log_files_in_group*innodb_log_file_size不能大于最大值512G）
innodb_flush_log_at_trx_commit：这个参数控制redo log的写入策略，它有0、1、2三种可能取值：
- 0：表示每次事务提交时都只是把redo log留在redo log buffer中，数据库宕机可能会丢失数据。
- 1(默认值)：表示每次事务提交时都将redo log直接持久化到磁盘，数据最安全，不会因为数据库宕机丢失数据，但是效率稍微差一点，线上系统推荐这个设置。
- 2：表示每次事务提交时都只是把redo log写到操作系统的缓存page cache里，这种情况如果数据库宕机是不会丢失数据的，但是操作系统如果宕机了，page cache里的数据还没来得及写入磁盘文件的话就会丢失数据。

1.3 undo log（回滚日志）

undo log（撤销日志）负责记录事务中的逆向操作，主要用于实现事务的回滚以及多版本并发控制（MVCC），确保事务的原子性（ACID中的A）。undo log并不是像其他日志那样被直接读取或查询的，而是由InnoDB引擎内部管理和使用。

1.3.1 日志结构

InnoDB对undo log文件的管理采用段的方式，也就是回滚段（rollback segment）。每个回滚段记录了 1024 个 undo log segment ，每个事务只会使用一个undo log segment。在MySQL5.5的时候，只有一个回滚段，那么最大同时支持的事务数量为1024个，从MySQL 5.6开始，InnoDB支持最大128个回滚段，故其支持同时在线的事务限制提高到了 128*1024 。

1.3.2 工作原理

事务开始时：InnoDB会在undo log中记录下所有被修改行的原始状态。
事务提交或回滚时：如果事务回滚，undo log中的记录将用于恢复数据到事务开始前的状态。如果事务提交，undo log记录会由后台purge线程在适当时候清理。(新增类型的，在事务提交之后就可以清除掉了；修改类型的，事务提交之后不会立即清除掉，因为这些日志会用于MVCC，只有当没有事务用到该版本信息时才可以清除)

1.3.3 关键参数

innodb_undo_directory：设置undo log文件所在的路径。该参数的默认值为"./"，即innodb数据文件存储位置，目录下ibdata1文件就是undo log存储的位置。
innodb_undo_logs：设置undo log文件内部回滚段的个数，默认值为128，更多的undo log可以提高并发事务的性能，但也占用更多的内存。
innodb_undo_tablespaces：设置undo log文件的数量，这样回滚段可以较为平均地分布在多个文件中。设置该参数后，会在路径innodb_undo_directory看到undo为前缀的文件。
innodb_purge_threads：设置purge线程的数量，这影响undo log的清理速度。

1.4 日志协作

在MySQL数据库中，尤其是在使用InnoDB存储引擎时，更新数据的过程是一个精心设计的序列，undo log、redo log、binlog之间的相互协议确保了数据的完整性和高效率。以下是更新数据流程示意图：

日志协作

初始化与缓存加载：当需要更新一条记录时，MySQL首先检查请求的数据是否在Buffer Pool中。如果不在，系统会从磁盘上的InnoDB表空间文件加载包含目标记录（例如ID为1的记录）的整个数据页到Buffer Pool中。数据库的增删查改都是直接操作Buffer Pool，通过缓存来加速数据访问速度，其大小通常配置为机器内存的60%左右。
事务日志准备：在更新数据之前，为了支持事务的可回滚性，MySQL会在undo日志中记录当前数据的原始状态。这意味着在事务提交前或回滚时，可以利用undo日志恢复Buffer Pool中的数据到更新前的状态。
内存中数据更新：接下来，InnoDB引擎在Buffer Pool中的数据页里直接更新记录，比如改变某行的name字段值为张三，这一操作发生在内存中，进一步提高了处理速度。
redo日志记录：为确保数据的持久性，更新操作的同时，相关更改会被记录到Redo Log Buffer中。redo日志是物理日志，记录了对数据页的物理变更，用于崩溃恢复，保证即使在系统故障后也能恢复数据到一致状态。
事务提交前的准备工作：
- redo log标记prepare：事务在真正提交前，会将写入redo日志中的记录标记为prepare，确保redo日志准备好事务提交或回滚。
- 预写日志：redo日志会先将数据本身被刷新到磁盘上，遵循WAL原则，确保即使数据库崩溃也能通过redo日志恢复数据。
- binlog记录：与此同时，MySQL还会将事务信息记录到二进制日志（Binlog）中，主要用于数据库磁盘里数据的复制和恢复。binlog记录的是SQL语句级别的逻辑变更，对于主从复制尤其重要。
事务提交确认：当redo日志和binlog都安全地写入磁盘后，会在redo日志中写入一个commit标记，标志着事务已经提交完成。这个标记是事务一致性的关键，确保redo日志和binlog之间的数据一致性。
数据落盘：虽然数据页的更新在内存中已经完成，但最终这些更新会以Page为单位随机写回到磁盘上的InnoDB表空间文件中。这个步骤可能不是立即发生的，依赖于MySQL的刷盘策略（如LRU算法管理的脏页刷新）。

MySQL通过其强大的日志体系（undo log、redo log和binlog），不仅保证了更新操作的高效执行，同时也确保了数据的ACID特性（原子性、一致性、隔离性、持久性）。

2 辅助日志

2.1 slow query log（慢查询日志）

慢查询日志用于监控和诊断那些执行时间过长的SQL查询。启用慢查询日志后，所有运行时间超过设定阈值的查询都会被记录到日志文件中，这有助于找出性能瓶颈并进行优化。

2.1.1 启用slow query log

修改配置文件：在my.cnf或my.ini配置文件中，按如下示例添加或修改[mysqld]段，之后重启MySQL服务：

[mysqld]
slow_query_log = ON 
slow_query_log_file = /{path}/slow-query-log.log
long_query_time = 2.5
log_queries_not_using_indexes = 1

slow_query_log = ON：设置为ON或1以开启慢查询日志。
slow_query_log_file：指定慢查询日志文件的路径和名称。如果未指定，MySQL将使用默认路径。
long_query_time：设置慢查询的阈值，单位是秒，默认值通常为10秒，意味着所有执行时间超过10秒的查询都将被记录。
log_queries_not_using_indexes：如果设置为ON或1，则会记录所有没有使用索引的查询，无论其执行时间如何。

动态修改：通过SET命令动态地开启或关闭慢查询日志，不过这种方式的更改不会持久化，服务器重启后会恢复默认设置。

SET GLOBAL slow_query_log = ON;
SET GLOBAL long_query_time = 2;
SET GLOBAL log_queries_not_using_indexes = ON;

2.1.2 查看slow query log

MySQL 5.6及更高版本提供了性能模式（Performance Schema），其中performance_schema.events_statements_history_long表可以存储慢查询信息。
也直接读取慢查询日志文件（例如，使用cat或less命令），下面是一个典型的慢查询日志条目的示例：

# Time: 2024-07-09T10:51:46.149675Z
# User@Host: root[root] @ localhost [::1]  Id:     8
# Query_time: 0.000236  Lock_time: 0.000098 Rows_sent: 1  Rows_examined: 5
SET timestamp=1720522306;
select * from account where balance = 450;

2.1.3 解析slow query log

使用EXPLAIN命令对慢查询日志记录的SQL语句来进行分析，找出性能瓶颈所在。

2.2 error log（错误日志）

错误日志记录了系统运行过程中遇到的问题、异常情况以及启动和关闭过程中的信息，是排查数据库故障的第一手资料可以通过show variables like '%log_error%'查看错误日志存放位置

2.3 general log（通用查询日志）

通用查询日志详细记录了客户端与MySQL服务器间的交互，包括所有SQL命令及结果，无论执行成功与否。由于资源消耗大，通常建议关闭，但在特定的调试场景下，如追踪特定操作或分析性能瓶颈时，开启通用查询日志能提供宝贵的信息。

2.3.1 启用general log

修改配置文件：在my.cnf或my.ini配置文件中，按如下示例添加或修改[mysqld]段，之后重启MySQL服务：

[mysqld]
general_log = ON
general_log_file = /{path}/general.log

动态修改：可以通过SET命令动态地开启或关闭通用查询日志。

SET GLOBAL general_log = ON;

2.3.2 关键参数

general_log：是否开启日志参数，默认为OFF，处于关闭状态，因为开启会消耗系统资源并且占用磁盘空间。一般不建议开启，只在需要调试查询问题时开启。
general_log_file：通用查询日志记录的位置参数。

2.4 relay log（中继日志）

中继日志在从服务器（Slave）上起着至关重要的作用。当从服务器设置为复制主服务器（Master）的数据时，中继日志用于存储和重放主服务器上发生的事务，以确保从服务器的数据与主服务器保持一致。

2.4.1 核心功能

数据同步：中继日志接收并存储来自主服务器的二进制日志（Binary Log）中的更改事件，这些事件随后会在从服务器上重放，以达到数据同步的目的。
缓冲作用：中继日志作为一种缓冲机制，允许主服务器在不等待从服务器完成事务重放的情况下继续记录新的更改事件，从而提高了复制效率和可靠性。

2.4.2 工作原理

I/O线程：从服务器上的I/O线程连接到主服务器，请求并接收二进制日志文件的更改事件，然后将这些事件写入本地的中继日志。
SQL线程：从服务器上的SQL线程读取中继日志中的事件，并在从服务器上执行这些事件，从而应用相同的数据更改。
进度跟踪：中继日志还维护着进度信息，包括已读取和已处理的事件位置，以便在失败后能够从上次成功的位置恢复复制。

3 结语

总之，MySQL的日志系统构成了保障数据安全、一致性和性能的精密网络。undo log、redo log、binlog各司其职，互为补充，共同维系着数据库的健康运行：undo log守护事务原子性与实现MVCC机制；redo log通过WAL策略确保了事务的持久性；binlog则支撑起数据复制与审计的重任；加上慢查询日志、错误日志、通用查询日志与中继日志对性能监控与数据同步的贡献，这一综合日志体系是MySQL强大功能和稳定性的保障，理解这一日志生态，是深度认识MySQL的必经之路，也是通往高效率数据库管理与开发实践的钥匙。

【MySQL】03. 日志体系