一、参数文件

当 MySOL 实例启动时，数据库会先去读一个配置参数文件，用来寻找数据库的各种文件所在位置以及指定某些初始化参数，这些参数通常定义了某种内存结构有多大等。

参数类型可以分为动态和静态两种，动态参数意味着可以在 MySOL 实例运行中进行更改，静态参数说明在整个实例生命周期内都不得进行更改，就好像是只读的

 

二、日志文件

1.错误日志

错误日志文件对 MySQL的启动、运行、关闭过程进行了记录。MySOL DBA 在遇到问题时应该首先查看该文件以便定位问题。该文件不仅记录了所有的错误信息，也记录一些警告信息或正确的信息。用户可以通过命令 SHOW VARIABLES LIKE 'log error'来定位该文件

2.慢查询日志

慢查询日志（slow log）可帮助 DBA定位可能存在问题的 SOL语句，从而进行 SOL 语句层面的优化。例如，可以在 MySQL 启动时设一个阈值，将运行时间超过该值的所有 SQL 语句都记录到慢查询日志文件中。DBA 每天或每过一段时间对其进行检查，确认是否有 SQL语句需要进行优化。该阈值可以通过参数 long_query_time来设置，默认值为 10，代表 10秒。 在默认情况下，MySQL 数据库并不启动慢查询日志，用户需要手工将这个参数设为ON

3.查询日志

查询日志记录了所有对MYSQL数据请求的信息 ，无论这些请求是否得到了正确的执行，默认文件名为：主机名.log

4.二进制日志

二进制日志（binary log）记录了对 MySQL 数据库执行更改的所有操作，但是不包括 SELECT和 SHOW这类操作，因为这类操作对数据本身并没有修改。然而，若操作本身并没有导致数据库发生变化，那么该操作可能也会写入二进制日志

作用：

恢复（recovery）∶某些数据的恢复需要二进制日志，例如，在一个数据库全备文 件恢复后，用户可以通过二进制日志进行 point-in-time 的恢复。

复制（replication）∶其原理与恢复类似，通过复制和执行二进制日志使一台远程 的 MySQL 数据库（一般称为 slave 或 standby）与一台 MySQL 数据库（一般称为 master 或 primary）进行实时同步。

审计（audit）∶ 用户可以通过二进制日志中的信息来进行审计，判断是否有对数 据库进行注入的攻击。

三、套接字文件

在 UNIX 系统下本地连接 MySQL 可以采用 UNIX 域套接字方式，这种方式需要一个套接字（socket）文件。套接字文件可由参数 socket 控制

四、pid 文件

当 MySQL实例启动时，会将自己的进程 ID 写入一个文件中——该文件即为 pid 文件。该文件可由参数 pid file 控制，默认位于数据库目录下，文件名为主机名 .pid

五、表结构定义文件

因为 MySQL 插件式存储引擎的体系结构的关系，MySQL 数据的存储是根据表进行的，每个表都会有与之对应的文件。但不论表采用何种存储引擎，MySOL 都有一个以 frm 为后缀名的文件，这个文件记录了该表的表结构定义。

六、 InnoDB存储引擎文件

之前介绍的文件都是 MySOL 数据库本身的文件，和存储引擎无关。除了这些文件外，每个表存储引擎还有其自己独有的文件。与 InnoDB存储引擎密切相关的文件，这些文件包括重做日志文件、表空间文件。

1.表空间文件

InnoDB 采用将存储的数据按表空间（tablespace）进行存放的设计。在默认配置下会有一个初始大小为 10MB，名为ibdatal 的文件。该文件就是默认的表空间文件（tablespace file），用户可以通过参数 innodb data file path 对其进行设置

设置 innodb data file path参数后，所有基于InnoDB存储引擎的表的数据都会记录到该共享表空间中。若设置了参数 innodb file per table，则用户可以将每个基于 InnoDB 存储引擎的表产生一个独立表空间。独立表空间的命名规则为∶表名 .ibd。通过这样的方式，用户不用将所有数据都存放于默认的表空间中。

2. 重做日志文件

在默认情况下，在 InnoDB存储引擎的数据目录下会有两个名为 ib logfileO 和ib logfilel 的文件。在 MySQL 官方手册中将其称为 InnoDB 存储引擎的日志文件，不过更准确的定义应该是重做日志文件（redo log file）。为什么强调是重做日志文件呢?因为重做日志文件对于 InnoDB 存储引擎至关重要，它们记录了对于 InnoDB存储引擎的事务日志，当实例或介质失败（media failure）时，重做日志文件就能派上用场。例如，数据库由于所在主机掉电导致实例失败，InnoDB 存储引擎会使用重做日志恢复到掉电前的时刻，以此来保证数据的完整性。 每个 InnoDB 存储引擎至少有1个重做日志文件组（group），每个文件组下至少有 2 个重做日志文件，如默认的 ib_logfile0和 ib_logfilel。为了得到更高的可靠性，用户可以设置多个的镜像日志组（mirrored log groups），将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行

正是因为重做日志的存在才使得InnDB存储引擎可以提供可靠的事务

重做日志文件和二进制文件的区别

首先，二进制日志会记录所有与 MySQL 数据库有关的日志记录，包括 InnoDB、 MyISAM、Heap 等其他存储引擎的日志。而InnoDB 存储引擎的重做日志只记录有关该存储引擎本身的事务日志。
其次，记录的内容不同，无论用户将二进制日志文件记录的格式设为 STATEMENT还是 ROW，又或者是 MIXED，其记录的都是关于一个事务的具体操作内容，即该日志是逻辑日志。而 InnoDB 存储引擎的重做日志文件记录的是关于每个页（Page）的更改的物理情况。
此外，写入的时间也不同，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这时该事务多大。而在事务进行的过程中，却不断有重做日志条目被写入到重做日志文件中