Mysql DBA基础第一篇（4）：MySQL文件

一.错误日志
作用：记录mysqld启动或停止时，以及服务器在运行过程中发生任何严重错误时的相关信息。
如果不指定名称或称路径的话（不在my.cnf中进行设置得话）。
他会以本机名称作为文件名，并以err作为文件扩展名，存放的路径和数据目录是在一起的。
以下可以通过进程直接查看www.err的所在路径（www是本机名称），一般来说都是在数据目录下的。
也可以这样：

二.通用日志
作用：记录所有连接和语句（DML呀DDL呀）。
由于通用日志记录了所有的查询，所以一定要记得关闭它，否则，在一个生产繁忙的系统中，通用日志在几小时之内可能就会塞满磁盘。
以下是他是否打开（off没打开）及他的路径。
我们没有打开，所以不存在该文件。

三.二进制日志
作用：记录所有对数据库进行更改的操作，不包括select和show（毕竟他们不改数据库）。
二进制日志的主要目的是恢复数据（万一出现了生产事故，误删等操作时，我们需要将数据库恢复到特定时间的状态）和复制（复制指的是通过主库的二进制日志将数据复制到从库），因为二进制日志包含备份后进行的所有更新。
1.查看有多少二进制日志存在

能发现102764406/1024/1024 = 98MB左右

2.查看当前的二进制日志到哪了（position的变化，也就是二进制日志文件大小的变化）
同时也可以看出select和show不会写入二进制日志。
能看到多了296个字节。（如果是row行级的话有可能会导致二进制日志增长过快，因为statement只记录一句语句，而row记录行的信息更改，如果是一张大表，更新某个字段，那的话增长是很快的）
3.二进制日志缓存区大小和二进制日志缓存的命中率与临时文件使用率
通过临时文件(Binlog_cache_disk_use)与写入内存缓冲区（Binlog_cache_use）的比较能够发现32KB的内存缓冲空间区的大小目前是够了。
不够的话可以调整一下日志缓冲区的大小，对IO是有好处的。

4.二进制日志文件的格式
MySQL有三种记录命令的形式，一种是语句级（binlog_format=statement），一种是行级（binlog_format=row），还有一种是混合形的（binlog_format=mixed）。
1）语句级（statement-based）
单纯的SQL。
2）行级（row-based）
如果是行级格式的日志，那么它所记录的事件信息包含了行的更改信息而不是原始的SQL语句。
3）混合（mixed）
就是包含上面两者，默认情况下记录的是SQL语句，个别情况下就是行级了，推荐用混合。

我这边一开始是行级的，看不到SQL的。后来被我改成了mixed。

4）查看binlog记录的日志
在linux终端输入
mysqlbinlog --no-defaults --database=MyTest --base64-output=decode-rows --start-datetime=‘2021-04-28 10:00:00’ --stop-datetime=‘2021-04-29 15:00:00’ /var/lib/mysql/binlog.000023 | more

上面的意思是指，查看binlog.000023日志在2021-04-28 10:00:00——2021-04-29 15:00:00中MyTest数据库所记录的日志内容 。
□ #at 1328：事件的起始点
#后面的是时间段end_log_pos指下一个事件的开始点，其实也就是这个事件的终点+1。（能看到后面那个就是1457了）
Query thread_id=14 exec_time=0 error_code=0：
thread_id指执行这个SQL的线程id。exec_time在主从库中有不同的含义，在主库中，等于执行这个事件所花费的时间；在从库中，等于这个事件结束执行的时间点减去在主库上开始执行的时间点，这个差异可以表征主从之间的滞后程度。error_code为错误状态，等于0时表示状态正常。

5.二进制日志文件的过期策略
对于二进制日志文件可以设置合适的过期策略binlog_expire_logs_seconds设置会在运行flush logs命令后触发删除过期的日志。
以下是修改二进制日志过期策略的步骤：

1）默认的二进制日志过期时间是30天。

2）查看数据目录下的二进制日志。
能看到我中间几次压测的时候已经堆了很多空间了。

3）修改过期策略

4）flush logs以后失效策略生效。
5）持久化一下，要不然重启一下就么得了= =毕竟默认是30天
四.独立表空间
这边设置为ON就表示InnoDB数据表可以各自存储为一个文件，称为独立表空间，它用于存放数据、索引等。

能看到MyTest目录（数据库）下面有五张表，且都是以ibd结尾的。

五.pid文件
当MySQL实力启动时，会将自己的进程ID写入一个文件中——该文件即为pid文件。ps：安装的时候报错贼烦= =
默认路径是在数据目录下

六.套接字文件
服务器用来与本地客户端进行通信的Linux套接字文件（也称为socket文件）。如果该文件被删除将导致MySQL无法通过socket文件的方式进行登录，一般在\tmp下。
七.表结构定义文件
8.0下面.frm文件被移除了。

八.重做日志文件（redo log）
作用：记录InnoDB的事务日志，奔溃恢复，保证事务的持久性，也就是每当有事务提交，就必须确保事务都已经写入重做日志文件。
每个InnoDB引擎至少有1个重做日志文件组，每个组下面至少有2个重做日志文件。
如默认的ib_logfile0、ib_logfile1
过小的事务日志会导致频繁的磁盘IO。
我们这边 Log sequence number 到 Last checkpoint at 的差距为53MB
一般来说,innodb_log_file_size * innodb_log_files_in_group * 0.75必须大于这个53MB才是合适的，而我们这边是48MB * 2 * 0.75=72mb,相对于目前的业务系统来说还是合适的。

九.undo日志
Undo log是InnoDB MVCC事务特性的重要组成部分。当我们对记录做了变更操作时就会产生undo记录。
Undo记录中存储的是老版本数据，当一个旧的事务需要读取数据时，为了能读取到老版本的数据，需要顺着undo链找到满足其可见性的记录。

如果一个事务长时间未提交，而我们默认使用的是repeatableread事务隔离级别，那么InnoDB不会去清理旧的行版本（oldrow versions），因为未提交的事务仍然需要看到它。当这个事务一直保持打开而不提交，就可能会导致大量旧的版本数据无法删除，从而导致undo暴涨。将事务的隔离级别更改为readcommitted可以解决此问题(读提交)。但根本的处理措施还是检查代码，找到未提交的事务。

在灾难恢复过程中，它也扮演了重要的角色，它的主要功能是在灾难恢复过程中回滚那些没有提交的变更。