MySQL——日志
日志的作用
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 = 1server_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