1. 参数文件
MySQL实例启动时，数据库会先读取参数文件，用来寻找数据库的各种文件所在位置以及指定某些初始化参数。与Oracle数据库不同的是，如果没有配置参数文件，MySQL启动时，会加载默认值。
静态参数是只读的，动态参数可以在MySQL实例运行中进行更改，其修改范围可以参考MySQL官方手册中 Dynamics System Variables相关内容。
2. 日志文件
2.1 错误日志（error log）
该文件记录了所有的错误信息，也记录了一些警告信息和正确信息。可以通过命令 SHOW VARIABLES LIKE 'log_error' 来定位该文件
2.2 慢查询日志（slow query log）
可以在MySQL启动时设一个阈值（long_query_time = 10000ms），将运行时间超过该值的所有SQL语句都记录到慢查询日志中。如果运行的SQL语句没有使用索引（log_throttle_queries_not_using_indexes，每分钟未使用索引的SQL语句多少次后加入慢查询日志），也会被加入到慢查询日志中。
2.3 二进制日志（binlog）
二进制日志记录了对MySQL数据库执行更改的所有操作（不包括SELECT SHOW等操作）。主要有以下几种作用：
- 恢复（recovery） 通过二进制日志进行point-in-time 的恢复 （第八章介绍）
- 复制（replication）通过复制和执行二进制日志使一台远程的MySQL数据库（一般为slave）与一台MySQL数据库（master）进行实时同步。
- 审计（audit） 用户可以通过二进制日志中的信息来进行审计，判断是否有对数据库进行注入的攻击。
参数sync_binlog = [N]表示每写缓冲多少次就同步到磁盘（所有未提交的二进制日志会被记录到一个缓存中去，等事务提交时，直接将缓存中的二进制日志写入二进制日志文件）。若N为1，表示采用同步写磁盘的方式来写二进制日志（如果不是同步写的，数据库宕机时，可能最后一部分数据没有写入二进制日志文件中）。但是设为1，还是有一种情况导致问题发生。当使用InnoDB存储引擎时，在一个事务发出COMMIT动作之前，由于sync_binlog为1，因此将二进制日志立即写入磁盘中。如果这时写入了二进制日志，但是还未提交日志，发生了宕机。那么在MySQL数据库下次启动时，由于COMMIT操作并没有发生，这个事务应该被回滚掉。但是二进制日志已经记录了该事务信息，所以不能被回滚。通过设置参数innodb_support_xa为1来解决，该参数确保二进制日志和InnoDB存储引擎数据文件的同步。
binlog_format 参数设置二进制文件的格式：
- STATEMENT 二进制日志文件记录的是逻辑SQL语句
- ROW 二进制日志文件记录的是表中行的更改情况（文件相应更大）
- MIXED
2.4 查询日志（log）
记录了所有对MySQL数据库请求的信息，无论这些信息是否得到了正确的执行。
3. InnoDB存储引擎文件
3.1 表空间文件
InnoDB将存储的数据按表空间（tablespace）进行存放。
3.2 重做日志文件（redo log）
每个InnoDB存储引擎至少有1个重做日志文件组，每个文件组下至少有两个重做日志文件，如默认的ib_logfile0和ib_logfile1。为了获得更高的可靠性，用户可以设置多个镜像日志组，将不同的文件组放在不同的磁盘上，以此提高重做日志的高可用性。在日志组中，每个重做日志文件的大小一致，并以循环写入的方式运行。从重做日志缓冲往磁盘写入时，是按512字节，也就是一个扇区的大小进行写入。因为扇区是写入的最小单位，所以重做日志的写入过程不需要doublewrite。
重做日志和二进制日志的区别？
由binlog 和redo log的区别可知：binlog日志只用于归档，只依靠 binlog 是没有crash-safe 能力的。但只有 redo log 也不行，因为 redo log 是 InnoDB特有的，且日志上的记录写入磁盘后会被覆盖掉。因此需要 binlog 和 redo log 二者同时记录，才能保证当数据库发生宕机重启时，数据不会丢失。
