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中的信息进行安全审计,从而判断是否存在对数据库的注入攻击。
二进制日志的保存
二进制日志文件记录的是一个事务的具体操作内容,它是逻辑日志。
二进制日志文件,只在事务提交前写磁盘,即二进制日志只写一次磁盘。
- 当开启一个事务,对表中的数据进行操作时,所有未提交的二进制日志会记录到缓存中去,等到该事务提交时,将缓存中的二进制日志写入磁盘上的二进制日志文件中。
- 配置项: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存储引擎》一书阅读过后的二次创作,文件颇多截图引用书中插图,此外本文主要用作个人学习后的思考感悟的记录,不如原书讲得深入且全面,强烈建议购买原书深入了解更多的细节。