Mysql中的各种日志

1.binlog（二进制日志）

        MySQL中的binlog，全称为Binary Log（二进制日志），是MySQL数据库的一种日志文件，主要记录了数据库中所有修改了数据的SQL语句或者二进制的变乱，用来保证数据的一致性与恢复。具体来说，binlog记录了所有的DDL（Data Definition Language，数据定义语言）和DML（Data Manipulation Language，数据操作语言）语句，但不包罗纯查询语句（如SELECT）和一些无需修改数据的操作（如SHOW等）。binlog是MySQL复制和数据恢复的基础，具有以下几个主要作用。
（1）数据复制：binlog是MySQL实现主从复制的基础。在主从复制架构中，主服务器会记录所有修改数据的操作到binlog中，而从服务器通过读取这些binlog记录并在本身的数据库上重新执行这些操作，从而实现与主服务器数据的同步。
（2）数据恢复：在数据库发生故障时，可以使用binlog来进行点的恢复。例如，假如数据库在某个时间点之后的数据由于操作错误或者其他原因被破坏，可以通过恢复到最近的备份，然后使用binlog中记录的日志，重新执行从备份时间点到故障时间点之间的所有操作，从而实现数据的恢复。
（3）审计：通太过析binlog的内容，可以查看在某个时间段内数据库中发生了哪些数据修改操作，这对于跟踪数据变动汗青、进行安全审计等都非常有效。
（4）增量备份：利用binlog可以实现增量备份，即备份自前次备份以来发生的所有数据变动。这种备份方式比完整备份更高效，尤其是在数据量大的情况下。

        上图表示了binlog 的四种读写作用场景，即数据恢复、数据复制（数据备份）、数据库分布式读写、数据库主从读写分离。
        为了有效地使用binlog，需要在MySQL的配置文件（如my.cnf或my.ini）中开启binlog，并配置干系参数，好比：

• log_bin：启用binlog，并设置binlog文件的名称。
  
• max_binlog_size：设置binlog文件的最大巨细。
  
• binlog_format：设置binlog的格式，可以是STATEMENT（基于SQL语句）、ROW（基于行的变革）或MIXED（混合模式）。
  
• expire_logs_days：管理binlog还需要注意其巨细，由于随着时间的推移，binlog大概会占用大量磁盘空间。因此，需要定期清算或归档旧的binlog文件，以释放空间并保持系统性能。可以通过设置expire_logs_days参数来主动删除过期的binlog文件。
  

Statement
每一条会修改数据的sql都会记录在binlog中。
长处：不需要记录每一行的变革，淘汰了binlog日志量，节流了IO，提高性能。
Row
5.1.5版本的MySQL才开始支持row level 的复制，它不记录sql语句上下文干系信息，仅保存哪条记录被修改。
长处：row level 的日志内容会非常清晰的记录下每一行数据修改的细节。而且不会出现某些特定情况下的存储过程，或function，以及trigger的调用和触发无法被正确复制的问题。
Mixed
从5.1.8版本开始，MySQL提供了Mixed格式，实际上就是Statement与Row的结合。
2.错误日志

        MySQL的错误日志是MySQL数据库中用于记录数据库启动、运行或停止时出现的问题的日志文件。这些记录包罗MySQL服务器的各种错误、告诫和紧张的系统信息，对数据库管理员进行故障排查和性能调优非常有效。错误日志具有以下几个紧张作用。
（1）故障诊断

• 错误日志提供了关于MySQL服务器运行中发生的错误的具体信息，如启动失败、连接错误、语法错误等。
  
• 管理员可以通过查看错误日志中的错误信息，快速定位问题的原因，进而接纳相应的办理措施。
  

（2）系统检控

• 通过定期查抄错误日志，可以及时发现并处理潜伏的问题，如配置错误、性能瓶颈或安全风险。
  
• 错误日志中的信息可以帮助管理员了解系统的运行状态，从而进行优化和调解。
  

（3）恢复参考

• 在发生系统瓦解或不测中断的情况下，错误日志可以提供瓦解前的末了运动记录，这对于数据恢复和系统重启有紧张参考价值。
  

启用错误日志
        在MySQL的配置文件（通常是my.cnf或my.ini）中，可以设置错误日志的文件路径：

1. [mysqld]
2. log_error = /path/to/your/log-file.err

复制代码

假如没有明白设置log_error选项，MySQL通常会在数据目次中主动创建一个错误日志文件。错误日志的查看可以直接通过访问其文件路径来进行，或者通过干系的管理工具来查看。随着运行时间的增长，错误日志的巨细大概会增长很快，特别是在出现很多错误或告诫的情况下。定期轮换和备份日志文件是一个好习惯，可以使用如logrotate这样的工具来帮助管理日志文件。
3.变乱日志

        mysql的变乱有 4 种特性：原子性、一致性、隔离性和持久性。那么变乱的四种特性到底是基于什么机制实现呢？
变乱的隔离性由锁机制实现。
而变乱的原子性、一致性和持久性由变乱的 redo 日志和 undo 日志来保证。

• Redo Log：又称为重做日志，提供再写入操作，恢复提交变乱修改的页操作，用来保证变乱的持久性。记录的是物理级别上的页修改操作，好比页号xxx、偏移量 yyy 写入了 ‘zzz’ 数据。主要为了保证数据的可靠性；
  
• Undo Log：又称为回滚日志，回滚行记录到某个特定版本，用来保证变乱的原子性、一致性。记录的是逻辑操作日志，好比对某一行数据进行了 INSERT 语句操作，那么 undo log 就记录一条与之相反的 DELETE 操作。主要用于变乱的回滚（undo log 记录的是每个修改操作的逆操作）和一致性非锁定读（undo log 回滚行记录到某种特定的版本—MVCC，即多版本并发控制）
  

3.1Redo日志

        InnoDB 存储引擎是以页为单位来管理存储空间的。在真正访问页面之前，需要把在磁盘上的页缓存到内存中的 Buffer Pool 之后才可以访问。所有的变动都必须先更新缓冲池中的数据，然后缓冲池中的脏页会以肯定的频率被刷入磁盘（checkPoint 机制），通过缓冲池来优化 CPU 和磁盘之间的鸿沟，这样就可以保证团体的性能不会下降太快。
        InnoDB 引擎的变乱接纳了 WAL 技术 (Write-Ahead Logging )，这种技术的头脑就是先写日志，再写磁盘，只有日志写入乐成，才算变乱提交乐成，这里的日志就是 redo log。当发生宕机且数据未刷到磁盘的时候，可以通过 redo log 来恢复，保证 ACID 中的 D，这就是 redo log 的作用。

redo日志的组成
Redo log 可以简单分为以下两个部分：
（1）重做日志缓冲 (redo log buffer)，保存在内存中，是易失的。在服务器启动时就向操作系统申请了一大片称之为 redo log buffer 的连续内存空间，翻译成中文就是 redo 日志缓冲区。这片内存空间被划分成若干个连续的 redo log block。一个 redo log block 占用 512 字节巨细。
（2）重做日志文件 (redo log file)，保存在硬盘中，是持久的。
redo的团体流程如下图

第 1 步：先将原始数据从磁盘中读入内存中来，修改数据的内存拷贝；
第 2 步：生成一条重做日志并写入 redo log buffer，记录的是数据被修改后的值；
第 3 步：当变乱 commit 时，将 redo log buffer 中的内容刷新到 redo log file，对 redo log file接纳追加写的方式；
第 4 步：定期将内存中修改的数据刷新到磁盘中；
3.2Undo日志

        undo log 是变乱原子性的保证。在变乱中更新数据的前置操作其实是要先写入一个 undo log。
（1）变乱需要保证原子性，也就是变乱中的操作要么全部完成，要么什么也不做。但有时候变乱执行到一半会出现一些情况，好比：
        情况一：变乱执行过程中大概遇到各种错误，好比服务器本身的错误， 操作系统错误 ，乃至是突然断电导致的错误。
        情况二：步伐员可以在变乱执行过程中手动输入 ROLLBACK 语句结束当前变乱的执行。
（2）以上情况出现，我们需要把数据改回原先的样子，这个过程称之为回滚，这样就可以造成一个假象：这个变乱看起来什么都没做，所以符合原子性要求。
（3）每当我们要对一条记录做改动时（这里的改动可以指 INSERT、DELETE、UPDATE，不包罗 SELECT），都需要"留一手"——即把回滚时所需的东西记下来。好比：
        你插入一条记录时，至少要把这条记录的主键值记下来，之后回滚的时候只需要把这个主键值对应的记录融掉就好了。(对于每个INSERT，InnoDB 存储引擎会完成一个DELETE）
你删除了一·条记录，至少要把这条记录中的内容都记下来，这样之后回滚时再把由这些内容组成的记录插入到表中就好了。（对于每个DELETE，InnoDB 存储引擎会执行一个 INSERT）你修改了一个记录，至少要把修改这条记录前的旧值都记录下来，这样之后回滚时再把这条记录更新为旧值就好了。（对于每个UPDATE，InnoDB 存储引擎会执行一个相反的 UPDATE，将修改前的行放归去）
（4）MySQL 把这些为了回滚而记录的这些内容称之为打消日志或者回滚日志（即 undo log）。注意，由于查询操作 (SELECT) 并不会修改任何用户记录，所以在查询操作执行时，并不需要记录相应的 undo 日志。此外，undo log 会产生 redo log，也就是 undo log 的产生会陪同着 redo log 的产生，这是由于 undo log 也需要持久性的保护。
undo+redo日志生成过程（简要）
（1）假设有 2 个数值，分别为 A = 1 和 B = 2，然后将 A 修改为3 ，B 修改为 4。

1. 1. start transaction;
2. 2. 记录 A = 1 到 undo log;
3. 3. update A = 3;
4. 4. 记录 A = 3 到 redo log;
5. 5. 记录 B = 2 到 undo log;
6. 6. update B =4;
7. 7. 记录 B = 4 到 redo log;
8. 8. 将 redo log 刷新到磁盘;
9. 9. commit;

复制代码

在 1 ~ 8 步调的任意一步系统宕机，变乱未提交，该变乱就不会对磁盘上的数据做任何影响。
假如在 8 ~ 9 之间宕机，恢复之后可以选择回滚，也可以选择继续完成变乱提交
由于此时 redo log 已经持久化。若在 9 之后系统宕机，内存映射中变动的数据还来不及刷回磁盘，那么系统恢复之后，可以根据 redo log 把数据刷回磁盘。
4.慢查询日志

        MySQL的慢查询日志是MySQL提供的一种日志类型，用于记录执行时间凌驾特定阈值的SQL查询。这个功能主要用来辨认数据库操作中的性能瓶颈，从而帮助数据库管理员优化查询语句和改进数据库性能，其主要作用如下：
（1）性能分析

• 慢查询日志提供了一个记录所有执行时间凌驾预设阈值的SQL语句的机制。这使得开发者和数据库管理员能够辨认和优化那些对性能影响最大的查询。
  

（2）优化数据库

• 通太过析慢查询日志中的信息，可以确定需要添加索引的地方、需要改写的查询、大概存在的表设计问题等。这有助于淘汰数据库的相应时间和提拔应用的团体性能。
  

（3）监控与警报

• 在一些高级的监控系统中，慢查询日志可以被用作生成性能警报的依据，及时通知管理员接纳行动。
  

如何启用慢查询日志及其干系参数
（1）启用慢查询日志
        在MySQL的配置文件（通常是my.cnf或my.ini）中设置以下参数以启用慢查询日志：

1. [mysqld]
2. slow_query_log = 1
3. slow_query_log_file = /path/to/your/log-file
4. long_query_time = 2

复制代码

其中，slow_query_log用于启用慢查询日志，slow_query_log_file指定日志文件的存储位置，long_query_time设置查询执行的时间阈值（单位是秒），凌驾这个时间的查询会被记录。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。