Mysql_InnoDB_文件
Mysql_InnoDB_文件
Mysql数据库和InnoDB存储引擎存储的文件如下:
- 参数文件
- 日志文件
- Socket文件
- pid文件
- Mysql表结构文件
- 存储引擎文件
参数文件
记录数据库文件的位置、初始化参数等。Mysql实例启动时依据这些数据找到数据库文件,并设定相应的参数,这些参数通常定义了某种内存结构的大小等。
Mysql中的数据库参数可以看成一个键值队。比如innodb_buffer_pool_size=2G。其中,键是innodb_buffer_pool_size,值为2G。
Mysql中的参数可分为动态参数(可以在Mysql实例运行中进行修改)和静态参数(在Mysql运行期间不能修改),可以通过SET命令队动态参数进行修改。
mysql> SET @@global.read_buffer_size=362144\G;
Query OK, 0 rows affected, 1 warning (0.00 sec)
ERROR:
No query specified
mysql> SELECT @@session.read_buffer_size\G;
*************************** 1. row ***************************
@@session.read_buffer_size: 262144
1 row in set (0.00 sec)
ERROR:
No query specified
mysql> SELECT @@global.read_buffer_size\G;
*************************** 1. row ***************************
@@global.read_buffer_size: 360448
1 row in set (0.00 sec)
ERROR:
No query specified
其中global和session关键字表示参数的修改是基于当前会话还是该数据库实例的整个生命周期。
值得注意,当修改了全局的参数,当前会话的对应的值并不会改变。
静态变量在实例运行中修改,会抛出错误:
mysql> set global datadir='/';
ERROR 1238 (HY000): Variable 'datadir' is a read only variable
日志文件
常见的Mysql日志文件有:错误日志、二进制日志、慢查询日志、查询日志。这些日志文件可以有效的监控和诊断mysql运行的状态,找出问题并进行优化或改善。
错误日志
该文件记录了Mysql实例在启动、关闭和运行过程中的错误信息和一些警告或正确的信息。当Mysql实例出现问题时,可以通过该文件定位问题并解决。
可以通过命令show variables like ‘log_error’;来找到该文件。
show variables like 'log_error';
+---------------+----------------+
| Variable_name | Value |
+---------------+----------------+
| log_error | ./xijianlv.err |
+---------------+----------------+
1 row in set (0.00 sec)
慢查询日志
错误日中的信息可以有助于优化和解决数据库层面的问题。慢查询日志用来定位SQL语句中可能存在的问题。
long_query_time
该参数表示,运行时间超过此阈值的sql将记录到慢查询日志文件中。默认为10秒。
mysql> show variables like 'long_query_time'\G;
*************************** 1. row ***************************
Variable_name: long_query_time
Value: 10.000000
1 row in set (0.00 sec)
mysql> show variables like '%slow_query_log%';
+---------------------+-----------------------------------------+
| Variable_name | Value |
+---------------------+-----------------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /usr/local/mysql/data/xijianlv-slow.log |
+---------------------+-----------------------------------------+
2 rows in set (0.01 sec)
默认设置下,Mysql不启动慢查询日志。
log_queries_not_using_indexes
此参数表示,如果sql没有使用索引,Mysql数据库同样会把这条sql记录到慢查询日志文件中(默认设置下,此参数的值为OFF)。
mysql> show variables like 'log_queries_not_using_indexes';
+-------------------------------+-------+
| Variable_name | Value |
+-------------------------------+-------+
| log_queries_not_using_indexes | ON |
+-------------------------------+-------+
1 row in set (0.00 sec)
实际情况下,如果没有使用索引的sql也记录到slow log,会导致slow文件不断增大,增加排查难度。参数log_throttle_queries_not_using_indexes用来表示每分钟记录到slow log的sql语句次数(默认为0,表示没有限制)。
mysqldumpslow
随着越来越多的sql被记录到慢查询日志中,此时想分析该文件就比较难了。Mysql为了解决这个问题,提供了mysqldumpslow命令。
mysqldumpslow常用的参数:
-s,是order的顺序
-----al 平均锁定时间
-----ar 平均返回记录时间
-----at 平均查询时间(默认)
-----c 计数
-----l 锁定时间
-----r 返回记录
-----t 查询时间
-t,是top n的意思,即为返回前面多少条的数据
-g,后边可以写一个正则匹配模式,大小写不敏感的
slow_log表
在mysql架构下,有名为slow_log的表,将馒查询日志存放在此表中,更易查看,表结构如下:
mysql> show create table mysql.slow_log\G;
*************************** 1. row ***************************
Table: slow_log
Create Table: CREATE TABLE `slow_log` (
`start_time` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6) ON UPDATE CURRENT_TIMESTAMP(6),
`user_host` mediumtext NOT NULL,
`query_time` time(6) NOT NULL,
`lock_time` time(6) NOT NULL,
`rows_sent` int(11) NOT NULL,
`rows_examined` int(11) NOT NULL,
`db` varchar(512) NOT NULL,
`last_insert_id` int(11) NOT NULL,
`insert_id` int(11) NOT NULL,
`server_id` int(10) unsigned NOT NULL,
`sql_text` mediumblob NOT NULL,
`thread_id` bigint(21) unsigned NOT NULL
) ENGINE=CSV DEFAULT CHARSET=utf8 COMMENT='Slow log'
1 row in set (0.00 sec)
要使用此表,需要将动态参数log_output,设置为TABLE。默认为FILE。
查询日志
查询日志记录了所有对Mysql数据库请求的信息,无论这些请求的执行结果如何。
同样的,也可以将查询日志的记录存放至mysql库下的general_log表中。
二进制日志
二进制日志记录了对Mysql数据库执行更改的所有操作,不包括Select和Show这类操作。(如果修改操作并没有导致数据库发生变化,也有可能会记录进二进制日志)
mysql> UPDATE account SET balance=100.1 WHERE id=100;
Query OK, 0 rows affected (0.02 sec)
Rows matched: 0 Changed: 0 Warnings: 0
mysql> show master status\G;
*************************** 1. row ***************************
File: mysql-bin.000074
Position: 497
Binlog_Do_DB:
Binlog_Ignore_DB:
Executed_Gtid_Set:
1 row in set (0.00 sec)
mysql> show binlog events in 'mysql-bin.000074'\G;
*************************** 1. row ***************************
Log_name: mysql-bin.000074
Pos: 4
Event_type: Format_desc
Server_id: 1
End_log_pos: 123
Info: Server ver: 5.7.19-log, Binlog ver: 4
*************************** 2. row ***************************
Log_name: mysql-bin.000074
Pos: 123
Event_type: Previous_gtids
Server_id: 1
End_log_pos: 154
Info:
*************************** 3. row ***************************
Log_name: mysql-bin.000074
Pos: 154
Event_type: Anonymous_Gtid
Server_id: 1
End_log_pos: 219
Info: SET @@SESSION.GTID_NEXT= 'ANONYMOUS'
*************************** 4. row ***************************
Log_name: mysql-bin.000074
Pos: 219
Event_type: Query
Server_id: 1
End_log_pos: 298
Info: BEGIN
*************************** 5. row ***************************
Log_name: mysql-bin.000074
Pos: 298
Event_type: Query
Server_id: 1
End_log_pos: 417
Info: use `exam`; UPDATE account SET balance=100.1 WHERE id=100
*************************** 6. row ***************************
Log_name: mysql-bin.000074
Pos: 417
Event_type: Query
Server_id: 1
End_log_pos: 497
Info: COMMIT
6 rows in set (0.00 sec)
可以看出,UPDATE的修改操作返回的结果中Changed为0,数据库中的记录没有因此而变化,但是二进制日志文件中记录了此sql。
二进制日志的用途如下:
- 恢复:某些数据的恢复需要进行二进制日志。例如数据库全备文件恢复后,可以通过二进制文件进行point-in-time的恢复。
- 复制:通过复杂和执行二进制日志使一台愿承担Mysql数据库(slave或standby)与另一台Mysql数据库(master或primary)实际实时同步。
- 审计:可以通过二进制日志中的信息进行审计,判断是否有对数据库的注入攻击。
和二进制日志相关的参数
max_binlog_size:单个二进制日志文件的最大值。默认为1073741824(1G).
binlog_cache_size:当使用事务的表存储引擎,未提交的二进制日志会被写入缓存中,等事务提交之后将缓存中的二进制日志写入到二进制文件,binlog_cache_size觉得该缓存的大小,默认32k。此缓存是基于会话到,也就是说当一个线程开启一个事务时,Mysql就会自动分配一个binlog_cache_size的缓存,如果该缓存不足以存储二进制日志,Mysql会被缓冲中的日志写入一个临时文件。
mysql> show variables like 'binlog_cache_size'; +-------------------+-------+ | Variable_name | Value | +-------------------+-------+ | binlog_cache_size | 32768 | +-------------------+-------+ 1 row in set (0.00 sec) //缓存大小32k mysql> show global status like 'binlog_cache%'; +-----------------------+-------+ | Variable_name | Value | +-----------------------+-------+ | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 1 | +-----------------------+-------+ 2 rows in set (0.00 sec) //缓存此时1次。 //临时文件使用次数0次。
sync_binlog:表示没写缓存多少次就同步到磁盘一次。当设置为1,表示每次缓存都同步到磁盘。
binlog-do-db和binlog-ignore-db:表示需要写入或忽略那些库的日志。默认为空。
log-slave-update:数据库中的slave角色,不会从master去的并执行的二进制日志写入自己的二进制日志文件中。如果需要,设置此参数。如果需要搭建master->slave->slave架构的复制,则必须设置该参数。
binlog_format:记录二进制日志的格式。可选的参数有:
- STATEMENT,二进制日志文件记录的是日志的逻辑sql语句。
- ROW,二进制日志文件记录行更改情况。
- MIXED,默认使用STATEMENT,有些情况使用ROW。
binlog_format是动态参数,可以在数据库运行时进行更改。将binlog_format设置为row可以使数据库的恢复和复制更加的可靠。但是,这样会使二进制日志文件大小增加,对磁盘空间的要求进一步增加。
二进制日志文件格式为二进制,无法用cat、head等名称来查看。可以通过Mysql提供的mysqlbinlog对文件进行查看。
套接字文件
Unix系统下本地连接Mysql可用Unix域套接字方式,这种方式需要一个套接字(socket)文件。套接字文件可有参数socket控制。
mysql> show variables like 'socket';
+---------------+-----------------+
| Variable_name | Value |
+---------------+-----------------+
| socket | /tmp/mysql.sock |
+---------------+-----------------+
1 row in set (0.00 sec)
pid文件
Mysql实例启动时,会将自己的进程ID写入到一个文件中,该文件为pid文件。由参数pid_file控制。
mysql> show variables like 'pid_file';
+---------------+------------------------------------+
| Variable_name | Value |
+---------------+------------------------------------+
| pid_file | /usr/local/mysql/data/xijianlv.pid |
+---------------+------------------------------------+
1 row in set (0.00 sec)
表结构定义文件
Mysql采用插件式存储引擎,所有数据的存储是依据表的,每个表有与之对应的后缀为frm的文件,记录该表的表结构定义。
视图的定义也是用frm文件存放。
InnoDB存储引擎文件
前面的文件都是Mysql数据库本身的文件,和存储引擎无关。每张表的存储引擎也有单独的文件。
表空间文件
InnoDB采用将存储的数据按表空间进行存放的设计。默认情况下有一个名为ibdata1的文件。该文件就是默认的表空间文件(tablespace file)。可以通过innodb_data_file_path进行设置。
innodb_data_file_path = ibdata1:100M;ibdata2:100M:autoextend
将ibdata1和ibdata2两个文件组成一个表空间。如果不在统一磁盘上,磁盘的复制可能被平均,因此可以提高数据库整体性能。同时文件名后的属性表示,两个文件的大小为100M,文件ibdata2如果用完的100M,将自动增长。
如果设置了innodb_data_file_path参数后,所有基于InnoDB存储引擎的表的数据都会记录到该表空间。若设置innodb_file_per_table,可以将每个基于InnoDB存储引擎的表产生一个独立表空间,命名规则:表名.idb。
xijianlv:exam lv$ ls -lh|grep ibd
-rw-r----- 1 lv _mysql 96K 12 19 2018 account.ibd
-rw-r----- 1 lv _mysql 96K 1 4 2018 dept.ibd
-rw-r----- 1 lv _mysql 112K 1 10 2019 emp.ibd
-rw-r----- 1 lv _mysql 96K 1 7 2018 hasband.ibd
-rw-r----- 1 lv _mysql 14M 11 23 2018 item.ibd
-rw-r----- 1 lv _mysql 448K 11 23 2018 liter.ibd
-rw-r----- 1 lv _mysql 11M 11 23 2018 literature.ibd
-rw-r----- 1 lv _mysql 92M 11 23 2018 pvideo.ibd
-rw-r----- 1 lv _mysql 96K 1 4 2018 salgrade.ibd
-rw-r----- 1 lv _mysql 96K 1 4 2018 stu.ibd
-rw-r----- 1 lv _mysql 160K 1 10 2018 t_stu.ibd
-rw-r----- 1 lv _mysql 96K 1 10 2018 t_user.ibd
-rw-r----- 1 lv _mysql 7.0M 3 19 2019 tab_bin.ibd
-rw-r----- 1 lv _mysql 96K 12 19 2018 test.ibd
-rw-r----- 1 lv _mysql 96K 3 29 2019 testtt.ibd
-rw-r----- 1 lv _mysql 96K 1 4 2018 wife.ibd
重做日志
默认情况下,InnoDB存储引擎的数据目录下会有名为ib_logfile0和ib_logfile1的文件。这两个文件就是重做日志文件(redo log file),它们记录了对InnoDB存储引擎的事物日志。
当实例或者介质失败时,InnoDB会使用重做日志文件恢复到宕机之前的时刻,保证时间的完整性。
每个InnoDB存储引擎至少有一个重做日志文件组,每个文件组下至少有两个重做日志文件(默认的ib_logfile0和ib_logfile1)。用户还可以设置多个镜像日志组,讲不通的文件组房子不通的磁盘上,来提高重做日志的可用性。日志组中的每个重做日志文件的大小一致,并以循环写入的方式运行。
上图显示来三个重做日志文件的重做日志文件组。InnoDB存储引擎先写重做日志文件1,当达到文件的最后时,切换至文件2。
影响重做日志文件的属性:
- innodb_log_file_size:每个重做日志文件的大小。
- innodb_log_files_in_groups:日志文件组中重做日志文件的数量,默认为2.
- innodb_mirrored_log_groups:指定日志镜像文件组的数量,默认为1.表示只有一个日志文件组,没有镜像。
- innodb_log_group_home_dir:日志文件组所在的路径,默认为./,表示在Mysql数据库的数据目录下。
重做日志条目结构
redo_log_type | space | page_no | redo_log_body |
---|---|---|---|
1字节,重做日志的类型 | 表空间ID | 页的偏移量 | 重做日志的数据不符,恢复时调用相应的函数 |
space和page_no均采用压缩的方式,因此space的空间可能小于4字节。
本文地址:https://blog.csdn.net/shui2104/article/details/107498795