MySQL日志

目录

 错误日志

查询日志

二进制日志 

慢查询日志 

redo log 和 undo log （事务日志）

          redo log：

         undo log：

---

mysql> show variables like 'log_%';



返回所有以"log_"开头的系统变量和它们的值，这些变量控制了MySQL服务器的日志记录行为。

常见的日志变量包括：

log_output：指定日志记录输出的目标，包括文件、表、控制台等。
log_error：指定错误日志输出的文件名。
general_log：控制是否记录所有SQL语句到通用查询日志文件。
slow_query_log：控制是否启用慢查询日志功能。
log_bin：控制是否启用二进制日志功能。

 错误日志

        记录了当 mysqld 启动和停止时，以及服务器在运行过程 中发生任何严重错误时的相关信息。当数据库出现任何故障导致无法正常使用时，可以首先查看此日 志。

        mysqld 使用错误日志名 host_name.err(host_name 为主机名) 并默认在参数 DATADIR(数据目录)指定 的目录中写入日志文件。

查询日志

        查询日志记录了客户端的所有语句。由于上线项目sql特别多，开启查询日志IO太多导致MySQL效率 低，只有在调试时才开启，比如通过查看sql发现热点数据进行缓存。

mysql> show global variables like "%genera%";

二进制日志 

        二进制日志(BINLOG)记录了所有的 DDL(数据定义语言)语句和 DML(数据操纵语言) 语句，但是不包括 数据查询语句。语句以“事件”的形式保存，它描述了数据的更改过程

。 此日志对于灾难时的数据恢复起 着极其重要的作用。

两个重要的应用场景：主从复制、数据恢复

查看binlog：mysql> show binary logs; 

通过mysqlbinlog工具（mysql原生自带的工具）可以快速解析大量的binlog日志文件，如：

shell> mysqlbinlog --no-defaults 

--database=school  //库名

--base64-output=decode-rows -v

--start-datetime='2021-05-01 00:00:00' --stop-datetime='2021-05-10 00:00:00' //时间段

mysql-bin.000001 | more

 show master logs；

用于显示 MySQL 主服务器上所有已经被写入的二进制日志文件名。

如何开启二进制日志：

• 修改MySQL配置文件my.cnf，在[mysqld]下添加以下配置：

log-bin=mysql-bin

• 重启MySQL服务；

• 使用以下命令检查是否开启了二进制日志：

SHOW VARIABLES LIKE 'log_bin';

慢查询日志 

        当SQL执行的时间超过我们设定的时间，那么这些SQL就会被记录在慢查 询日志当中，然后我们通过查看日志，用explain分析这些SQL的执行计划，来判定为什么效率低下，是 没有使用到索引？还是索引本身创建的有问题？或者是索引使用到了，但是由于表的数据量太大，花费 的时间就是很长，那么此时我们可以把表分成n个小表，比如订单表按年份分成多个小表等。

慢查询日志相关的参数如下所示：

set slow_query_log = ON;  设置慢查询日志打开（全局）

慢查询日志记录了包含所有执行时间超过参数 long_query_time（单位：秒）所设置值的 SQL语句的日 志，在MySQL上用命令可以查看，如下：

这个值是可以修改的，如下：（局部的）

 现在修改成超过1秒的SQL都会被记录在慢查询日志当中！可以设置为0.01秒，表示10毫秒。

慢查询日志，默认名称是host_name-slow.log，存放在MySQL的数据路径下（/var/lib/mysql），内容格式显示大致如 下：

 通过查询慢查询日志，发现项目运行过程中，上面这条SQL语句的执行时间超过了设定的慢查询时间， 那么接下来就需要用explain分析一下该SQL的执行计划了，根据具体情况找出SQL和索引该怎么去优化。

redo log 和 undo log （事务日志）

          redo log： 

        重做日志，用于记录事务操作的变化，确保事务的   。redo log是在事务开始后就开始记录，不管事务是否提交都会记录下来，在异常发生时（如数据持久化过程中掉电），InnoDB会使用redo log恢复的到掉电前的时刻，保证数据的完整性。

        innodb_log_buffer_size默认是16M，就是redo log缓冲区的大小，随着事务的开始就开始记录redo log，如果事务比较大，为了避免事务执行过程中花费过多的磁盘IO可以设置更大的redo log缓存节省磁盘IO。 

        innodb_buffer_pool_size缓存池、缓存数据缓存索引 默认是134m

        InnoDB修改操作数据过程：

        不是直接修改磁盘上的数据，实际只是修改Buffer Pool上的数据。InnoDB总是先把Buffer Pool中的数据改变记录到redo log中，用来进行崩溃后的数据恢复。优先记录redo log，然后再慢慢将buffer pool中的脏数据刷新到磁盘上。

        一个事务commit提交数据的时候，首先将InnoDB Log buffer写入磁盘，成功写入时才会变成commit状态，写入失败任然是prepare状态；

        因为InnoDB Log Buffer写入磁盘这个过程也可能出现错误（发生异常、掉电、服务崩溃）任然是事务没有提交成功的状态！（事务最重要的是写redo log，而不是写数据）

        Buffer Pool中是改变过的数据，会有另外的线程找个合适的时间写入磁盘，不需要和commit操作同步。

         undo log：

        回滚日志，保存了事务发生之前的数据的一个版本，用于事务执行时的回滚操作，同时也是实现多版本并发控制（MVCC）下读操作的关键技术。

        undo log 也是要记录在redo log中

        会在表中添加两列：DB_TRX_ID:事务ID           DB_ROLL_PTR:回滚指针

各个版本数据被记录，存放在链表中。