InnoDB存储引擎3-文件

参数文件

参数

查看参数的访问

  • 通过命令查看show variables

  • 通过information_schema架构下的global_variables视图查找

参数类型

  • 动态参数:set global|session 参数;set @@global|@@session 参数

  • 静态参数

日志文件

错误日志

查看错误日志文件的位置:show variables like ‘log_error’.

慢查询日志

  • 查看慢查询SQL时间:show variables like “long_query_time”。

  • 查看慢查询是否开启:show variables like “log_slow_queries”。

  • 记录未使用索引的sql:log_queries_not_using_indexes;

  • 慢查询类型 slow_query_type .涉及sql语句,IO,运行时间。

  • 记录逻辑IO过多的SQL:long_query_io.

  • mysqldumpslow 命令 很好的实现慢查询的梳理。肯定有图形化工具

  • Mysql5.1开始将慢查询放到slow_log表中。

    • 参数log_output指定了慢查询的输出格式 File 或者 Table。这个参数可以在线修改,并且是全局的。也可以修改slow_log表的存储引擎。

查询日志

开启查询日志:set global general_log = on

日志名称:主机名.log。

也可以以表的形式保存。general_log。

二进制日志

二进制日志记录了对Mysql数据库执行更改的所有操作,不包括select和show操作。

BINLOG日志作用:

  • 恢复(recovery):某些数据恢复需要二进制日志,例如,在一个数据库全备文件恢复后,用户可以通过二进制日志进行point-in-time的恢复。

  • 复制(replication):其原理与恢复类似,通过复制和执行二进制日志使一台远程的Mysql数据库与另一条数据进行实时同步。

  • 审计(audit):用户可以通过二进制日志中的信息来进行审计,判断是否有对数据库进行注入的攻击。

binlog参数设置:

  • max_binlog_size:单个文件最大值

  • binlog_cache_size:事务未提交SQL存放buffer大小。每个回话所有,不能设置过大(导致内存不够),也不能设置过小(sql信息写到临时文件中)。可以通过查看binlog_cache_use、binglog_cache_disk_use的状态判断。

  • sync_binlog :表示每次写缓冲多少次就同步到磁盘。高可用mysql一定要设置为1。防止宕机导致的日志缺失。对于事务是先写binlog再执行,SQL为成功执行的情况下,会导致数据不一致。可以通过innodb_support_xa来解决。详细可查看浅析innodb_support_xa与innodb_flush_log_at_trx_commit

-binlog-do-db和 binlog-ignore-db表示需要写入或者忽略写入哪些库的日志

  • bin_format,日志格式。可能导致二进制日志格式。rand、uuid参数,事务隔离级别。日志格式有statment:记录日志的逻辑SQL语句;row:记录表的更改情况;mixed:一些情况使用statment,一些情况使用row,使用row的情况1)表的存储引擎为NDB 2)使用UUID、User等不确定函数。3)使用insert delay语句 4)用户定义函数UDF 5)使用了临时表。通常情况,我们使用ROW格式。

参看binlog 使用mysqlbinlog

套接字文件

在Unix系统下本地连接Mysql可以使用unix域套接字方式。show variables like ‘socket’,查看文件位置。

pid文件

当mysql实例启动时,会将自己的进程id写入一个文件中,该文件即为pid文件。show variables like ‘pid_file’,查看文件位置。

表结构定义文件

MYSQL都有一个以frm为后缀名的文件,这个文件记录了该表的表结构定义。frm还用来存放视图的定义。

InnoDB存储引擎文件

表空间文件

参数innodb_data_file_path 表空间文件路径设置。

公共表空间 ibdata1 ibdata2。

参数innodb_file_per_table,每个表产生一个独立表空间。

单独表空间文件近存储该表的数据、索引和插入缓冲BITMAP等信息,其余信息还是存放在默认的表空间。

重做日志文件

每个InnoDB存储引擎至少有一个重做日志组,每个问价组下至少有2个重做日志文件,默认的ib_logfile0和ib_logfile1。InnoDB存储引擎先写重做日志文件1,当到达文件的最后时,会切换至重做日志文件2,再当重做日志文件2也被写满时,会在切换到重做日志文件1中

二进制日志与重做日志的区别

1
2
3
4
5
6

- 二进制日志惠济路所有与Mysql数据库有关的日志记录,包括InnoDB、MyISAM、Heap等其他存储引擎的日志。而InnoDB存储引擎的重做日志只记录有关改引擎本身的事务日志。

- 记录的内容不同,无论用户二进制日志文件记录的格式设为Statement还是Row,又或者是Mixed,其记录的都是关于一个事务的具体操作内容,即该日志是逻辑日志。而InnoDB存储引擎的重做日志文件记录的是关于每个页的更改的物理情况。

- 写入的时间也不同,二进制日志文件仅在事务提交前进行提交,即只写磁盘一次,不论这时改事务多大。而在事务进行的过程中,却不断有重做日志条目被写入到重做日志文件中

重做日志格式

InnoDB1.2为止,总共定义了51种重做日志类型。虽然各种重做日志类型不同,但是他们有着基本的格式。

重做日志 保证数据的一致性

1
2
3
4
5
6
7
8

写入重做日志文件的操作不是直接写,而是先写入一个重做日志缓冲中,然后按照一定的条件顺序地写入日志文件。

从重做日志缓冲往磁盘写入时,是按512个字节,也就是一个山区的大小进行写入。因为扇区是写入的最小单位,因此可以保证写入必定是成功的。因此在重做日志的写入过程中不需要doublewrite。

参数innodb_flush_log_at_trx_commit的有效值为0,1,2。0代表当提交事务时,并不将事务的重做日志写入磁盘上的日志文件,而是等待主线程每秒的刷新。1和2不同在于:1表示在执行commit时会重做日志缓冲同步写到磁盘,即伴有ssync的调用。2表示将重做日志异步写到磁盘,即写到文件系统的缓存中。因此不能保证执行commmit时肯定会写入重做日志文件,只是有这个动作发生。

因此为了保证事务的ACID中的持久性,必须将innodb_flush_log_at_trx_commit 设置为1,也就是每当有事务提交时,就必须保证事务都已经写入重做日志文件。
1
2

执行sql,并且写重做日志到缓存->执行comiit语句->重做日志写入磁盘->更新内存数据页