MySQL常见日志
1、常见日志
- 错误日志(error log)：对MySQL的启动、运行和关闭过程进行记录
- 二进制日志(bin log)：主要记录更改数据库数据的SQL语句
- 一般查询日志(general query log)：已建立连接的客户端发送给MySQL服务器的所有SQL记录，默认关闭
- 慢查询日志(slow query log)：记录执行时间超过long_query_time的查询的SQL语句，也是默认关闭
- 重做日志(redo log)：记录的是某个数据页的更改，主要用于崩溃恢复
- 回滚日志(undo log)：记录的是事务中的SQL语句，比如执行一条insert语句，那么undo log就记录相反的一条delete语句，主要用于事务回滚
主要的日志是慢查询日志、binlog、redo log和undo log
2、慢查询日志
我们一般在解决慢SQL查询问题的时候使用到慢查询日志，慢查询日志记录了执行时间超过long_query_time（默认10s）的所有查询，这个日志是默认关闭的
//设置开启
SET GLOBAL slow_query_log=ON
//查看long_query_time时间（默认10s）
SHOW VARIABLES LIKE ‘%long_query_time%’;
//修改long_query_time的值
SET GLOBAL long_query_time=5
在实际项目中，慢查询日志可能会比较大，我们可以借助MySQL官方的慢查询分析调优工具mysqldumpslow
3、binlog
binlog主要记录了MySQL数据库中数据的所有变化(数据库执行的所有DDL和DML语句)。
binlog主要用于数据的恢复，其中一个常见的应用场景就是主从复制。
binlog通过追加写的方式写入，没有大小限制，可以手动设置max_binlog_size参数设置每个binlog文件的最大容量，当文件大小达到指定值后，会生成新的一份binlog文件来保存日志，不会覆盖前面的日志。
4、redo log
redo log主要记录页的修改，比如某个页面某个偏移量处修改了几个字节的值以及具体被修改的内容是什么。redo log中的每一条记录包含了表空间号、数据页号、偏移量、具体修改的数据，甚至还有可能是记录修改数据的长度，取决于redo log类型。
redo log的写入属于顺序IO，采取的是循环写的方式，于binlog不同，当redo log写入的日志超过一定长度后，会覆盖之前的日志。
redo log用于保证事务的持久性，具有崩溃恢复的能力。在事务提交时，我们会将redo log按照刷盘策略刷到磁盘上去，这样即使MySQL宕机了，重启之后也能够恢复未能写入磁盘的数据，从而保证事务的持久性。
但是这并不一定保证数据不丢失，这与刷盘策略有关innodb_flush_log_at_trx_commit，这个值默认为1，设置为1时是不会丢失任何数据的。
5、undo log
undo log日志主要记录的是与事务所执行的SQL语句相反的SQL语句，比如执行一条删除语句delete，那么undo log里面就会记录一条相反的inser语句。
undo log主要用于事务的回滚操作和MVCC版本控制。事务的回滚操作只需通过undo log里面记录的sql语句可实现回滚操作，实现一致性。MVCC多版本控制，当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据版本是怎样的，从而让用户能够读取到当前事务操作之前的数据（快照读）。
6、binlog 和 redolog的区别
- 用处不同：binlog主要用于数据库还原，属于数据级别的数据恢复，比如主从复制。redolog主要用于保证事务的持久性，属于事务级别的数据恢复。
- 存储引擎不同：所有存储引擎都有binlog，只有InnoDB引擎才有redolog。
- 记录内容不同：redolog属于物理日志，主要记录的是某个页的修改。binlog属于逻辑日志，主要记录的是数据库执行的所有DDL和DML语句。
- 写入方式不同：redolog采用循环写的方式写入，binlog采用追加写的方式写入。
