概述
本文主要讲述MySQL数据库和Innodb存储引擎表的各种类型文件，主要包括如下内容：
-
参数文件
-
日志文件
-
socket 文件
-
pid文件
-
MySQL表结构定义文件
-
存储引擎文件
参数文件
启动时它告诉MySQL实例，在哪里可以找到数据库相关文件，除此之外参数文件中还指定某些初始化参数。
<linux参考：my.cnf，windows参考：my.ini>
类似Oracle的参数文件，但是MySQL如果找不到参数文件，也可以按照默认的初始化参数文件启动。
可以设置的参数非常多，例如：
- 设置缓冲池大小：innodb_buffer_pool_size=4G
- 开启二进制日志 binlog: log-bin=mysql-bin
参数包括动态参数和静态参数：
-
动态参数：可以在mysql运行过程中修改，区别是，有的动态参数只支持修改全局(@@globle)的参数值；而有的只能当前会话(@@session)生效(例如事务的：autocommit)；有的既可以是全局生效，又可以仅当前会话生效(例如：read_buffer_size)。
-
静态参数：业务运行的整个生命周期中都不能修改，只能通过参数文件修改，重启后生效。
日志文件
MySQL常见的日志文件有：
-
错误日志
-
慢查询日志
-
二进制日志
-
查询日志
错误日志
错误日志记录了mysql启动、运行、关闭过程中发生的错误或预警信息，可以通过如下方式查看错误日志路径。通过错误日志可以得知数据本身需要优化的地方。
慢查询日志
通过满查询日志，可以得知需要优化的SQL；
-
mysql通过参数：long_query_time 参数来控制慢查询日志的记录，默认值：10.0 (10秒)；默认不会开
-
启慢查询日志，需要设置如下参数手动开启，log_slow_queries=ON：
-
log_queries_not_using_indexes 设置为：ON，时会记录没有使用索引的SQL;
查询日志
查询日志记录了所有对MySQL的请求，无论其是否正确执行，默认文件名为：主机名.log。
二进制日志 binary log
二进制日志的配置
二进制日志记录对MySQL数据库执行更改的所有操作：INSERT UPDATE DELETE 等。
二进制日志默认不开启，需要通过配置项开启:
# mysql主从中，不重复的数字
server_id=1996
# 启用binlog开关，log_bin=[name] 如果不指定name，默认为主机名
log_bin = mysql-bin
# binlog模式
binlog_format = ROW
# 日志保留时间
expire_logs_days = 30
# 配置需要监听的库，多个库重复配置该配置项即可
binlog-do-db = supervise
# 单个二进制日志文件大小，单位：bit，默认值：1073741824
max_binlog_size =
通过如下指令可以查看binlog信息：
二进制日志的作用
-
恢复：某些数据的恢复需要二进制日志，用户可以通过二进制日志进行point-in-time的恢复。
-
复制：两台mysql 服务器间，通过复制和执行二进制日志来保证数据一致，一般搭建高性能的主从结构时会用到二进制日志(主从复制架构：修改通过master进行，查询通过slave支持，两者之间不能实时同步，存在一定延迟)；还有一个非常有名的应用，阿里的canal中间件，它把自己伪装成mysql的从库，接收主库发送的binlog。
-
审计：可以通过对binlog中的信息进行安全审计，从而判断是否存在对数据库的注入攻击。
二进制日志的保存
二进制日志文件记录的是一个事务的具体操作内容，它是逻辑日志。
二进制日志文件，只在事务提交前写磁盘，即二进制日志只写一次磁盘。
- 当开启一个事务，对表中的数据进行操作时，所有未提交的二进制日志会记录到缓存中去，等到该事务提交时，将缓存中的二进制日志写入磁盘上的二进制日志文件中。
- 配置项：binlog_cache_size可以控制该缓存的大小，默认值为32K，当会话二进制日志超过它时，会将缓存中的日志写入到一个临时文件中，该值不能设置得太大也不能设置得太小。
Binlog_cache_disk_use：二进制文件使用临时文件次数。
Binlog_cache_use：二进制文件使用缓冲次数。
从下图得知，使用临时文件次数为0，那么说明，当前缓冲大小合适，不需要修改。
- 在默认情况下，二进制日志并不是每次写的时候就刷新到磁盘
- 配置项sync_binlog = [N] 表示每当写多少次缓存就写一次磁盘，N=1 表示二进制日志同步写磁盘，当N配置一个比较大的值的时候，可以理解成，使用操作系统的缓冲写磁盘，但是这样可能会因为宕机导致二进制日志丢失。sync_binlog = 1 可以带来高可用，但是性能会有一定的影响。
-
已知再使用二进制日志时，当事务提交时会先将二进制日志写入磁盘，再将进行事务提交；如果这时发生了宕机，那么二进制日志写入成功，但是事务没有提交，重启时将会回滚事务，但是二进制日志已经被记录，不能回滚，这时需要开启配置项：innodb_support_xa = 1 ,通过它可以保证二进制日志记录与事务本身提交是一个原子操作。
-
二进制日志模式 binlog_format
-
STATEMENT：该模式下二进制日志记录的是SQL语句，它的好处是日志体积小，确定是可靠性低。
-
ROW：该模式下，二进制日志记录的是对表中每一行的修改；该模式下可以将事务隔离级别从 REPEATABLE READ 改为 READ COMMITED 以提高并发性。ROW模式的好处是：可靠性非常高，同样因为会记录每一行，所以磁盘空间开销较大。
例如对语句：update info_table set column_1 = 'test' where 1 =1。 二进制日志会记录，每一行的 column_1 被修改为： 'test'，而不只是简单的记录该sql。 -
MIXED：混合模式，默认使用STATEMENT 格式记录，但是在一些情况下使用ROW模式记录：
a. 存储引擎为：NDB，这时DML操作都记录为ROW b. 使用了：UUID()、USER()、CURRENT_USER()、FOUND_ROWS()、ROW_COUNT()等不确定函数 c. 使用了 INSERT DELAY 语句 d. 使用了用户定义函数：UDF e. 使用了临时表 temporary table
socket 套接字文件
套接字文件，UNIX 系统下，本地连接MySQL可以采用UNIX域套接字方式，这种方式需要一个套接字文件。套接字文件由参数socket控制，一般在 /tmp 目录下mysql.sock 文件中。
pid文件
MySQL 启动实例时，会将自己的进程ID 写入一个文件中(mysql的pid文件)，该文件由参数：pid_file进行控制，默认位于数据库目录下，主机名.pid。
MySQL表结构定义文件
在MySQL的插件式的存储体系中，数据以表的形式进行保存，每个表都有与之对应的文件。不论采用何种引擎，MySQL都有一个以frm为后缀的文件记录该表的结构定义。
Innodb 存储引擎文件
存储引擎文件包括：
- 表空间文件
- 重做日志文件
表空间文件
Innodb 将存储的数据按表空间进行存放，当设置了 innodb_data_file_path = [/path1/path2:[N]M] 参数后，所有基于innodb引擎的表都会存放到该该共享表空间；当设置了参数：innodb_file_per_table = ON 后,会为每个表创建独立的表空间。
重做日志文件
重做日志(redo log) 对于innodb 非常重要，它记录了Innodb 存储引擎的事务日志。当发生宕机，需要恢复数据时，它能起到非常重要的作用。为了提高重做日志的可用性，应该在不同的磁盘上为重做日志配置多个镜像组。
重做日志文件的大小，也非常重要，如果设置太大，恢复时需要很长时间。但是如果设置太小，那么可能导致一个事务的日志要切换多次重做日志文件；此外，回忆之前提到的checkpoint技术，重做日志太小会当重做日志文件不可用时，会频繁触发checkpoint 导致性能下降。
Innodb存储引擎的重做日志文件记录的是关于每个页的变更情况。
在事务过程中，会不断有重做日志被写到重做日志文件中。
本文来自我对 《MySQL技术内幕：InnoDB存储引擎》一书阅读过后的二次创作，文件颇多截图引用书中插图，此外本文主要用作个人学习后的思考感悟的记录，不如原书讲得深入且全面，强烈建议购买原书深入了解更多的细节。