MySQL技术内幕读书笔记（三）——文件

时间 2019-11-06

标签 mysql 技术内幕读书笔记文件栏目 MySQL 繁體版

原文原文链接

目录mysql

文件

文件

有如下类型文件sql

参数文件：告诉MYSQL实例启动时在哪里找到数据库文件，而且制定某些初始化参数。
日志文件：用来记录MYSQL实例对某种条件做出响应时写入的文件。
socket文件：当用UNIX域套接字方式进行链接时须要的文件。
pid文件：MYSQL实例的进程ID文件
MySQL表结构文件：用来存放MYSQL表结构定义文件。
存储引擎文件：

参数文件

查找参数文件命令数据库

mysql --help | grep my.cnf

查找参数值命令缓存

SELECT * FROM GLOBAL_VARIABLES WHERE VARIABLE_NAME LIKE 'innodb_buffer%'\G;

# 推荐使用
SHOW VARIABLES LIKE 'innodb_buffer%'\G;

分为两类服务器

动态参数
静态参数

动态参数能够在MYSQL实例运行进行更改，静态参数则是不可更改的。更改动态参数的语法以下：session

SET
| [global | session] system_var_name=expr
| [@@global. | @@session. | @@] system_var_name = expr

global：全局的，session：当前会话。说明参数的做用域是不通的。一些demo架构

# 改变当前会话，不会改变全局
SET read_buffer_size = 524288

# 改变全局会话参数，不会改变当前
SET @@global.read_buffer_size = 1048576;

# 查询当前会话参数
SELECT @@session.read_buffer_size\G;

# 查询全局会话参数
SELECT @@global.read_buffer_size\G;

可是这种修改，并不最终修改配置文件my.cnf的参数值，因此从新启动后，参数仍是按照配置文件中的加载。并发

日志文件

错误日志

记录了全部的错误信息、警告信息。查找错误日志文件位置异步

SHOW VARIABLES LIKE 'log_error'\G;

慢查询日志

记录查询慢的SQL，能够帮助优化。能够设置记录的阈值，而且打开开关socket

SHOW VARIABLES LIKE 'long_query_time'\G;
SHOW VARIABLES LIKE 'long_slow_queries'\G;

还有一个参数，若是SQL语句没有使用索引，就会加入到慢查询日志文件（slow log)中。

SHOW VARIABLES LIKE 'log_queries_not_using_indeces'\G;

# 设置每分钟容许记录到slow log的且未使用因此的SQL语句次数，缺省为0，表示没有限制。
SHOW VARIABLES LIKE 'log_throttle_queries_not_using_indexs'

可是若是数据量比较大的话，很差分析分件的话，可使用MYSQL提供的mysqldumpslow命令

# 从指定文件读取日志
mysqldumpslow nh122-190-slow.log

# 获得执行时间最长的10条SQL语句
mysqldumpslow -s al -n 10 david.log

还能够通过配置，在slow_log中查询慢日志

# 慢日志表名
SHOW CREATE TABLE mysql.show_log\G;

# 默认慢查询输出格式是FILE，则能够设为TABLE
SHOW VARIABLES LIKE 'log_output'\G;
SET GLOBAL log_output='TABLE';
SHOW VARIABLES LIKE 'log_output'\G;

# 查询慢日志
SELECT * FROM mysql.slow_log\G;

可是slow_log默认是用的CSV引擎，可以使用MyISAM引擎，提高查询效率（大数据量）

ALTER TABLE mysql.slow_log ENGINE=MyISM;
SET GLOBAL slow_query_log=off;
ALTER TABLE mysql.slow_log ENGINE=MyISM;

经过额外的参数记录相关信息到慢日志表中

经过参数long_query_io将超过指定逻辑IO次数的SQL语句记录到slow log中。默认值是100.

经过参数slow_query_type表示启动slow log的方式

0：不将SQL记录到slow log
1：根据运行时间将SQL语句记录到slow log
2：根据逻辑IO次数将SQL语句记录到slow log
3：根据运行时间以逻辑IO次数将SQL语句记录到slow log

查询日志

记录了全部对MYSQL数据库请求的信息，名字通常为主机名.log

二进制日志(binary log)

记录了对MYSQL数据库执行更改的全部操做。只要操做使得数据库发生变化，就会写入二进制日志。但操做若果未致使数据库发生变化，也有可能写入二进制日志。例如

UPDATE t SET a = 1 WHERE a = 2;

SHOW MASTER STATUS\G;
show binlog events in 'mysqld.000008'\G;

二进制日志主要做用

恢复：某些数据的恢复须要二进制文件。例如，在一个数据库全被文件恢复后，用户能够经过二进制日志进行point-in-time恢复
复制：经过复制和执行二进制日志使一台远程的MYSQL数据库(通常是slave或者standy)与一台MYSQL数据库(master或primary)进行实时同步。
审计：用户能够经过二进制日志中的信息来进行审计，判断是否有对数据库进行注入的攻击。

经过配置惨呼log-bin=[name]能够启动二进制日志。若是不指定name，则默认二进制日志文件名为主机名，后缀名为二进制日志的序列号。

# 查询二进制日志路径
show variablers like 'datadir';

# MYSQL调用LL
system ls -lh /user/local/mysql/data/;

bin_log.index为二进制的索引文件，用来存储过往产生的二进制日志序号。

如下配置文件的参数影响着二进制日志记录的信息和行为。

max_binlog_size：

指定单个二进制日志文件的最大值。默认为1G
binlog_cache_size：

当使用事务的表存储引擎（INNODB）时，全部未提交的二进制日志会被记录到一个缓存中去，等待事务提交时直接将缓冲中的二进制日志写入二进制日志文件，而缓冲的大小由binlog_cache_size决定，默认大小为32K。

值过大，浪费空间；值过小，会把缓冲中的日志写入到一个临时文件中。
```
# 查询设置的缓存大小
SHOW VARIABLES LIKE 'binlog_cache_size';

# 查看缓冲池状态
SHOW GLOBAL STATUS LIKE 'binlong_cache%';
```
sync_binlog：

默认状况下，二进制日志是使用缓冲写的方式，可是数据库宕机时，有可能缺乏一部分数据，给恢复和复制带来问题，因此使用参数sync_binlog=[N]表示每写缓冲多少次就同步到磁盘。若是N改为1的话，就是同步写磁盘来写二进制日志。可用性和IO性能须要进行取舍。

且当sync_binlog=1时，假设有事务还没commit，也会将二进制日志当即写入磁盘，可是若是发生宕机，二进制日志已经记录了该事务信息，不能回滚。这个问题能够经过将参数innodb_support_xa为1来解决。
binlog-do-db：

表示须要写入哪些库的日志
binlog-ignore-db：

表示须要忽略写入哪些库的日志
log-slave-update：

若是须要搭建master->slave->slave架构的复制，须要设置log-slave-update参数。
binlog_format：

很是重要，影响记录二进制日志的格式。
- STATEMENT：记录的是日志的逻辑SQL语句。
  
  这个对于复制是有必定要求的，若是再主服务器运行rand、uuid等函数，又或者使用触发器等操做，这些均可能会致使主从服务器上表中数据的不一致(not sync)。
  
  另外一个影响是：致使INNODB使用的默认事务隔离级别是REPEATABLE READ，若是使用READ COMMITTED的事务隔离界别，会出现相似丢失更新的现象，致使主从数据库上的数据不一致。
- ROW：记录表的行更改状况
  
  相似于Oracle的物理Standby，修复了Statement格式下的复制问题，也能够设置INNODB的事务隔离基本为READ COMMITTED，以获取更好的并发性。
- MIXED：默认采用STATEMENT格式进行二进制日志文件的记录，可是在一些状况下会使用ROW格式。
  - 表的存储引擎为NDB
  - 使用了UUID()、USER()、CURRENT_USER()等不肯定函数。
  - 使用了INSERT DELAY语句
  - 使用了用户定义函数(UDF)
  - 使用了临时表(temporary table)
查看二进制日志文件，只能使用MYSQL提供的工具mysqlbinlog

# 查看STATEMENT格式
mysqlbinlog --start-position=203 test.00004

# 查看ROW格式
mysqlbinlog -vv --start-position=203 test.00004

套接字文件

UNIX本地链接MYSQL能够采用UNIX域套接字方式，这种方式须要个套接字文件

pid文件

MYSQL实例启动时，会将本身的进程ID写入一个文件中——该文件即为pid文件。文件名由参数pid_file控制。

表结构定义文件

MYSQL数据的存储是根据表进行的，每一个表都会有与之对应的文件。但不论表采用何种存储引擎，MYSQL都有一个以frm为后缀名的文件，这个文件记录了该表的表结构定义。

也能够用来存放视图的定义。frm文件能够直接查看。

INNODB存储引擎文件

表空间文件

innoDB将存储的数据按表空间进行存放。在默认配置下会有一个ibdatal文件，该文件就是默认的表空间文件。能够经过参数innodb_data_file_path对其进行设置

innodb_data_file_path=datafile_spec1[;datafile_spec2]...

#demo 
#文件大小都设置为2000MB，其次ibdata2文件使用完2000M以后能够自动增加。
[mysqld]
innodb_data_file_path = /db/ibdatal:2000M;/dr2/db/ibdata2:2000M:autoextend

使用两个文件组成表空间，若两个文件位于不一样的磁盘，能够平均磁盘负载，提升数据的总体性能。设置以后全部数据都会存入共享表空间。若是设置参数innodb_filw_per_table就会给每一个表一个独立的存储空间。

SHOW VARIABLES LIKE 'innodb_file_per_table'\G;

注意，即便开启了上述参数，独立的表空间也只存储对应表的数据、索引和插入缓冲BITMAP等信息。其余信息仍是放在默认的表空间中。

重作日志文件

默认状况下，INNODB存储引擎的数据目录下会有两个名为ib_logfile0和ib_logfile1的文件。称为重作日志文件，在恢复时相当重要。

每一个INNODB存储引擎至少有一个重作日志文件组，每一个文件组下至少有2个重作日志文件。为了更高的可靠性，用户能够设置多个的镜像日志组，将不一样的文件组放在不一样的磁盘上，提升重作日志的可用性。

在日志组中每一个重作日志文件的大小一致，并以循环写入的方式运行。

下列参数严重影响重作日志文件的属性。

innodb_log_file_size

指定每一个重作日志文件的大小。

设置的过大，在恢复时可能须要不少的时间。设置的太小，一个事务须要屡次切换重作日志文件。还可能致使频繁的async checkpoint
innodb_log_files_in_group

指定日志文件组中重作文件的数量。
innodb_mirrored_log_grooups

指定日志镜像文件组的数量，默认为1.
innodb_log_group_home_dir

指定日志文件组所在路径。默认为./，表示在数据库的数据目录下

SHOW VARIABLES LIKE 'innodb%log%'\G;

事务日志和二进制日志的区别：

二进制会记录全部MYSQL数据库有关的日志记录。包括各类引擎的日志，而重作日志只记录有关该存储引擎自己的事务日志。
记录的内容不一样。二级制日志文件记录的是关于一个事务的具体操做，即该日志的逻辑日志。而INNODB存储引擎的重作日志文件记录的是关于每一个页的更改的物理状况。
写入的时间也不一样，二进制日志文件仅在事务提交前进行提交，即只写磁盘一次，不论这时事务多大。而在事务进行的过程当中，却不断有重作日志条目被写入到重作日志文件中。

INNODB存储引擎中，对于各类不一样的操做有着不一样的重作日志格式，可是基本格式相同。

1	2	3	4
reg_log_type	space	page_no	redo_log_body

由四个部分组成：

redo_log_type占用1字节，表示重作日志的类型。
space表示表空间的ID，但采用压缩的方式，所以占用的空间可能小于4字节。
page_on表示页的偏移量，一样采用压缩的方式
redo_log_body表示每一个重作日志的数据部分，恢复时须要调用响应的函数进行解析。

从重作日志缓冲往磁盘写入时，是按512字节（一个扇区）的大小进行写入。因此保障写入一定成功。不须要有doublewrite。

触发缓冲写入重作日志的条件：

主线程每秒会将重作日志写入磁盘的重作日志中，不论事务是否已经提交。
经过innodb_flush_log_at_trx_commit控制，表示在commit操做时，处理重作日志的方式
- 0：表示事务提交时，并不将事务的重作日志写入磁盘上的日志文件，而是等待主线程每秒的刷新
- 1：在执行commit时将重作日志缓冲同步写入磁盘
- 2：在执行commit时将重作日志缓冲异步写入磁盘，只保证这个动做会发生。

因此，为了保障ACID中的持久性，通常就把这个参数设置为1。