Innodb存储引擎的文件

目录

• 概述
• 参数文件
• 日志文件
  • 错误日志
  • 慢查询日志
  • 查询日志
  • 二进制日志 binary log
    • 二进制日志的配置
    • 二进制日志的作用
    • 二进制日志的保存
• socket 套接字文件
• pid文件
• MySQL表结构定义文件
• Innodb 存储引擎文件
  • 表空间文件
  • 重做日志文件

概述

本文主要讲述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中的信息进行安全审计，从而判断是否存在对数据库的注入攻击。

二进制日志的保存

二进制日志文件记录的是一个事务的具体操作内容，它是逻辑日志。
二进制日志文件，只在事务提交前写磁盘，即二进制日志只写一次磁盘。

1. 当开启一个事务，对表中的数据进行操作时，所有未提交的二进制日志会记录到缓存中去，等到该事务提交时，将缓存中的二进制日志写入磁盘上的二进制日志文件中。

• 配置项：binlog_cache_size可以控制该缓存的大小，默认值为32K，当会话二进制日志超过它时，会将缓存中的日志写入到一个临时文件中，该值不能设置得太大也不能设置得太小。

Binlog_cache_disk_use：二进制文件使用临时文件次数。

Binlog_cache_use：二进制文件使用缓冲次数。

从下图得知，使用临时文件次数为0，那么说明，当前缓冲大小合适，不需要修改。

2. 在默认情况下，二进制日志并不是每次写的时候就刷新到磁盘

• 配置项sync_binlog = [N] 表示每当写多少次缓存就写一次磁盘，N=1 表示二进制日志同步写磁盘，当N配置一个比较大的值的时候，可以理解成，使用操作系统的缓冲写磁盘，但是这样可能会因为宕机导致二进制日志丢失。sync_binlog = 1 可以带来高可用，但是性能会有一定的影响。

3. 已知再使用二进制日志时，当事务提交时会先将二进制日志写入磁盘，再将进行事务提交；如果这时发生了宕机，那么二进制日志写入成功，但是事务没有提交，重启时将会回滚事务，但是二进制日志已经被记录，不能回滚，这时需要开启配置项：innodb_support_xa = 1 ,通过它可以保证二进制日志记录与事务本身提交是一个原子操作。

4. 二进制日志模式 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存储引擎》一书阅读过后的二次创作，文件颇多截图引用书中插图，此外本文主要用作个人学习后的思考感悟的记录，不如原书讲得深入且全面，强烈建议购买原书深入了解更多的细节。