MySQL笔记之文件和日志

一、存储文件

1、存放位置

MySQL数据库会在data目录下，以数据库为名，为每一个数据库建立文件夹，用来存储数据库中的表文件数据。

不同的数据库引擎，每个表的扩展名也不一样 ，例如： MyISAM用“.MYD”作为扩展名，Innodb用“.ibd”等。

 

2、FRM表结构信息文件

无论是哪种存储引擎，创建表之后就一定会生成一个以表明命名的’.frm’文件。frm文件主要存放与表相关的数据信息，主要包括表结构的定义信息。当数据库崩溃时，用户可以通过frm文件来恢复数据表结构。

 

3、Innodb存储引擎文件

Innodb存储引擎的文件：后缀为 “.ibd” 和 “.ibdata” 的文件

这两种文件都是存放Innodb数据的文件，之所以有两种文件来存放Innodb的数据（包括索引），是因为Innodb的数据存储方式能够通过配置来决定是使用共享表空间存放存储数据，还是独享表空间存放存储数据。

 

独享表空间存储方式使用“.ibd”文件来存放数据，且每个表一个“.ibd”文件 ，文件存放在和MyISAM数据相同的位置。

 

独占表空间: 每一个表都将会生成以独立的文件方式来进行存储，每一个表都有一个.frm表描述文件（MySQL 8.0之前才有），还有一个.ibd文件。其中这个文件包括了 单独一个表的数据 内容以及索引内容。

 

共享表存储方式，则会使用“.ibdata“文件来存放，所有表共同使用一个（或者多个， 可自行配置）ibdata文件。

ibdata文件可以通过以下两个参数配置组成：

• innodb_data_home_dir（数据存放目录）
• innodb_data_file_path (配置每个文件的名称)
• innodb_data_file_path中可以一次配置多个ibdata文件 如：
• innodb_data_file_path = ibdata1:2000M;ibdata2:10M:autoextend 配置方式

 

二、日志分类

MySQL中有以下日志文件，分别是：

1：重做日志（redo log）

2：回滚日志（undo log）

3：二进制日志（binlog）

4：错误日志（errorlog）

5：慢查询日志（slow query log）

6：一般查询日志（general log）

7：中继日志（relay log）。

 

主要分析前三种。

 

1、redo log

（1）作用

确保事务的持久性。redo日志记录事务执行后的状态，用来恢复未写入data file的已成功事务更新的数据。防止在发生故障的时间点，尚有脏页未写入磁盘，在重启服务的时候，根据redo log进行重做，从而达到事务的持久性这一特性。

 

（2）内容

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

（3）什么时候产生

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

（4）什么时候释放

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

 

redoLog刷盘的时机由innodb_flush_log_at_trx_commit 参数控制。

 

2、undo log

 

（1）作用

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

（2）内容

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

（3）什么时候产生

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

（3）什么时候释放

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

（4）对应的物理文件

MySQL5.6之前，undo表空间位于共享表空间的回滚段中，共享表空间的默认的名称是ibdata，位于数据文件目录中。

MySQL5.6之后，undo表空间可以配置成独立的文件，但是提前需要在配置文件中配置，完成数据库初始化后生效且不可改变undo log文件的个数

如果初始化数据库之前没有进行相关配置，那么就无法配置成独立的表空间了。

 

3、binlog

binlog是逻辑格式的日志，类比Redis中的AOF持久化机制。

（1）作用

用于复制，在主从复制中，从库利用主库上的binlog进行重播，实现主从同步。

用于数据库的基于时间点的还原。

（2）内容

逻辑格式的日志，可以简单认为就是执行过的事务中的sql语句。

但又不完全是sql语句这么简单，而是包括了执行的sql语句（增删改）反向的信息，也就意味着delete对应着delete本身和其反向的insert；update对应着update执行前后的版本的信息；insert对应着delete和insert本身的信息。

（3）什么时候产生

事务提交的时候，一次性将事务中的sql语句（一个事物可能对应多个sql语句）按照一定的格式记录到binlog中。

因此对于事务的提交，即便是较大的事务，提交（commit）都是很快的，但是在开启了bin_log的情况下，对于较大事务的提交，可能会变得比较慢一些。

这是因为binlog是在事务提交的时候一次性写入的造成的，这些可以通过测试验证。

（3）什么时候释放

binlog的默认是保持时间由参数expire_logs_days配置，也就是说对于非活动的日志文件，在生成时间超过expire_logs_days配置的天数之后，会被自动删除。

 

MySQL通过两阶段提交过程来完成事务的一致性的，也即redo log和binlog的一致性的，理论上是先写redo log，再写binlog，两个日志都提交成功（刷入磁盘），事务才算真正的完成。