当前位置：首页 > news >正文

MySQL——日志

news 文章来源：https://blog.csdn.net/ZhouXin1111112/article/details/132779546 2025/4/3 18:27:08

日志的作用
   1.用来排错
   2.用来做数据分析
   3.了解程序的运行情况，是否健康--》了解MySQL的性能，运行情况

分类

mysql很多有类型的日志，按照组件划分的话，可以分为服务层日志和存储引擎层日志：
- 服务层日志：二进制日志、慢查日志、通用日志
- 存储引擎层日志：innodb(重做日志、回滚日志)

错误日志

错误日志是默认开启的，名字为主机名.err

记录：

登录失败会记录到错误日志
配置文件出错也会记录
启动过程出问题也会记录

如果指定错误日志的路径，主要目的地的目录需要给mysql用户写的权限

通用日志

缺点：消耗大量的磁盘空间；消耗cpu、内存、磁盘资源

优点：会记录所有的SQL操作

通用日志默认是不开启的

开启方式：

永久开启：修改配置文件

#general log
general_log
general_log_file=/data/mysql/sanchuang_mysql_ge.log

默认存放在数据目录下，名字是主机名.log

临时开启：mysql> set global general_log = 1; 1是开启 0 是关闭

慢日志

做优化时用，提升性能

作用：记录消耗时间比较长的SQL语句，为数据库性能提升提供了线索

最近数据库压力（负载特别高），客户反应网站或者应用使用特别慢，领导要求你查明原因？
1.SQL语句需要优化，在数据库里启用慢日志，找出执行时间比较长的SQL
2.业务量太大了，硬件已经达到极限了，top、glances、dstat

慢日志默认是关闭的

开启方式：

修改配置文件

存放在数据目录下，名字是主机名+slow.log

二进制日志

参考：https://www.cnblogs.com/liuhaidon/archive/2019/09/09/11493292.html

记录了什么？

DML语句、DDL、DCL等修改了数据的操作

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、DELETE、UPDATE…）的二进制日志

作用

1.可以用来恢复数据

2.主从复制

因为从服务器需要到主服务器里拷贝二进制日志，然后根据二进制日志的内容去执行SQL，从而达到主从服务器里的数据一模一样。

3.日志审计场景：用户可以通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入攻击。

MySQL的注入攻击：
用户（黑客）可以提交一段数据库查询代码，根据程序返回的结果，获得某些他想得知的数据，这就是所谓的SQL Injection，即SQL注入。

在哪里可以提交数据库查询代码？

二进制日志默认是关闭的

开启方式

修改配置文件

#开启二进制日志
log_bin
server_id = 1

server_id 是服务器的唯一标识，在主从复制的时候使用，每天服务器的id不能一样，不然会导致主从复制失败

存放的位置：数据目录下

主机名-bin.00000*
sc-mysql-bin.000001

总结

什么时候会产生二进制日志？

binlog是记录所有数据库表结构变更（例如CREATE、ALTER TABLE…）以及表数据修改（INSERT、UPDATE、DELETE…）的二进制日志。

二进制日志不是存储引擎管理的，是MySQL内部的相关线程去完成。

二进制日志保存下来有2个过程：
flush：将二进制日志写到binlog_buffer里
sync：将binlog_buffer里的内容刷盘到disk里binlog file

二进制的作用：
1.恢复数据（增量）
2.主从复制需要使用

二进制日志是如何写到磁盘里的？

刷盘时机

sync_binlog=0: 表示刷新binlog时间点由操作系统自身来决定，操作系统自身会每隔一段时间就会刷新缓存数据到磁盘，这个性能最好。--》容易丢失数据

sync_binlog=1: 表示每次事务提交都要调用fsync()，刷新binlog写入到磁盘。--》能快速的存储数据，不容易丢失数据

sync_binlog=N: 表示 N个事务提交，才会调用 fsync()进行一次binlog刷新，写入磁盘。

重做日志 redo log

作用：
确保事务的持久性。
防止在发生故障的时间点，尚有脏页未写入磁盘，在重启mysql服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。解决事务commit不成功，重新redo

内容：
物理格式的日志，记录的是物理数据页面的修改的信息，其redo log是顺序写入redo log file的物理文件中去的。

什么时候产生：
事务开始之后就产生redo log，redo log的落盘并不是随着事务的提交才写入的，而是在事务的执行过程中，便开始写入redo log文件中。

什么时候释放：
当对应事务的脏页写入到磁盘之后，redo log的使命也就完成了，重做日志占用的空间就可以重用（被覆盖）。

对应的物理文件位于数据库的data目录下的ib_logfile1&ib_logfile2

innodb 存储引擎产生的日志：
   redo log：记录的是脏数据的变化--》buffer pool里的
   作用：
       MySQL意外宕机重启也不要紧。只要在重启时解析redo log中的事务而后重做一遍。将Buffer Pool中的缓存页重作成脏页。后续再在合适的时机将该脏页刷入磁盘便可。

undo log：记录某数据被修改前的值
作用：方便回滚 rollback --》相当于做了一个快照（备份）

先写日志，再写数据

回滚日志 undo log

作用：
保存了事务发生之前的数据的一个版本，可以用于回滚，同时可以提供多版本并发控制下的读（MVCC），也即非锁定读

内容：
逻辑格式的日志，在执行undo的时候，仅仅是将数据从逻辑上恢复至事务之前的状态，而不是从物理页面上操作实现的，这一点是不同于redo log的。

什么时候产生：
事务开始之前，将当前是的版本生成undo log，undo 也会产生 redo 来保证undo log的可靠性

什么时候释放：
当事务提交之后，undo log并不能立马被删除，
而是放入待清理的链表，由purge线程判断是否由其他事务在使用undo段中表的上一个事务之前的版本信息，决定是否可以清理undo log的日志空间。

对应的物理文件：
MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。
MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数

到底是先产生undo log还是redo log

先redo，然后undo

分类