《第三章 InnoDB存储引擎表中的各种文件》

迈不过友情╰ 2022-04-25 04:18 45阅读 0赞

### 《第三章 InnoDB存储引擎表中的各种文件》 ###

*  参数文件
 *  日志文件
 *  套接字文件
 *  pid文件
 *  表结构定义文件
 *  INNODB存储引擎文件
 *   *  表空间文件
     *  重做日志文件

MySQL数据库和InnoDB存储引擎表的各种类型文件包括参数文件、日志文件、socket文件、pid文件、MySQL表结文件。

*  **参数文件：告诉MYSQL实例启动时在哪里找到数据库文件，并且制定某些初始化参数**。
 *  日志文件：用来记录MYSQL实例对某种条件作出响应时写入的文件。
 *  **socket文件：当用UNIX域套接字方式进行连接时需要的文件**。
 *  **pid文件：MYSQL实例的进程ID文件**
 *  **MySQL表结构文件：用来存放MYSQL表结构定义文件**。
 *  存储引擎文件：因为MySQL表存储引擎关系，每个存储引擎都会有自己的文件来保存各种数据。

# 参数文件 #

参数文件中存放着各种参数，例如innodb\_buffer\_pool\_size参数。参数文件可以在my.cnf中修改，

*  查找参数文件命令： mysql --help | grep my.cnf
 *  查找参数值命令:
 *      VARIABLE_NAME LIKE 'innodb_buffer%'\G;
        
        # 推荐使用 SHOW VARIABLES LIKE 'innodb_buffer%'\G;

参数分动态参数和静态参数：动态参数可以在MYSQL实例运行进行更改，静态参数则是不可更改的。更改动态参数的语法如下：global：全局的，session：当前会话。两者决定了动态参数的生命周期。

例如：我将read\_buffer\_size设置为524288，但是是session范围，如果有其他Mysql用户登录，使用该值会仍然是131072。  
                  ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70]  
其他demo:

# 改变当前会话，不会改变全局
    			SET read_buffer_size = 524288
    			
    			# 改变全局会话参数，不会改变当前
    			SET @@global.read_buffer_size = 1048576;
    			
    			# 查询当前会话参数
    			SELECT @@session.read_buffer_size\G;
    			
    			# 查询全局会话参数
    			SELECT @@global.read_buffer_size\G;

# 日志文件 #

**错误日志**： 记录了所有的错误信息、警告信息。查找错误日志文件位置 SHOW VARIABLES LIKE ‘log\_error’\\G;  
                  ![在这里插入图片描述][20190501100226400.png]  
由于我的/etc/my.cnf下配置了Log\_error = /var/log/mysqld.log  
            ![在这里插入图片描述][2019050110030230.png]  
**慢查询日志**：**慢查询能为SQL语句的优化带来很大的帮助**。  
默认情况下，MySQL数据库不支持慢查询日志：  
                  ![在这里插入图片描述][20190501100701339.png]  
在/etc/my.cnf，我的是这个配置文件，你可以用mysql --help | grep my.cnf查看：进行对慢查询配置，我的mysql版本是5.7，重启mysql。  
                ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 1]  
  但是很神奇，重启后，进行查询：你会发现好像配置文件并没有起作用  
                ![在这里插入图片描述][20190501104642672.png]  
  书中有这么一句话，需要手工将这个参数设置为ON。于是乎，用上面的参数设置方法进行设置，提示我/etc/my.cnf的mysql-slow.log没找到，这个目录因人而异，我是存放在此处。我在/logs目录下，新建了一个mysql-slow.log，重新手工设置。  
          ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 2]  
  然后可以用了：  
          ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 3]  
  得出的结论：有些参数通过更改Mysql的配置文件my.cnf如果重启后不生效，可以尝试用手工设置方法，手工设置是用SET指令进行设置哦。  
**查询日志： 记录了所有对MYSQL数据库请求的信息，名字一般为主机名.log**。  
**二进制日志(binary log)**：记录了对MYSQL数据库执行更改的所有操作。只要操作使得数据库发生变化，就会写入二进制日志。但操作若果未导致数据库发生变化，也有可能写入二进制日志。以下配置文件的参数影响着二进制日志记录的信息和行为，每一个参数具体的影响作用，参考书上。  
              ![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 4]  
可通过在/etc/my.cnf中配置log\_bin参数，从而配置二进制日志文件：  
                ![在这里插入图片描述][20190501112845607.png]  
  生成的日志路径可以先通过以下指令找到：  
                ![在这里插入图片描述][20190501112930912.png]  
  此时你会发现：有一个mysql-bin.00001即二进制日志文件。  
      ![在这里插入图片描述][20190501113018535.png]

# 套接字文件 #

查看套接字文件参考下面的命令：  
              ![在这里插入图片描述][20190501113251467.png]

# pid文件 #

![在这里插入图片描述][20190501113405636.png]

# 表结构定义文件 #

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

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

# INNODB存储引擎文件 #

## 表空间文件 ##

InnoDB存储引擎在存储设计上模仿了Oracle，将存储的数据按表空间进行存放。默认配置下，会有一个初始化大小为10MB、**名为ibdataI的文件。该文件就是默认的表空间文件**(tablespace file )。你可以通过参数innodb\_data\_file\_path对其进行设置。格式如下:  
![在这里插入图片描述][20190501114038465.png]  
 innoDB将存储的数据按表空间进行存放。在默认配置下会有一个ibdatal文件，该文件就是默认的表空间文件。可以通过参数innodb\_data\_file\_path对其进行设置。  
![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 5]

## 重做日志文件 ##

默认情况下，INNODB存储引擎的数据目录下会有两个名为ib\_logfile0和ib\_logfile1的文件。称为重做日志文件，**在恢复时至关重要**。 每个INNODB存储引擎至少有一个重做日志文件组，每个文件组下至少有2个重做日志文件。为了更高的可靠性，用户可以设置多个的镜像日志组，将不同的文件组放在不同的磁盘上，提高重做日志的可用性。 在日志组中每个重做日志文件的大小一致，并以循环写入的方式运行。图3-2显示了一个拥有3个重做日志文件的重做日志文件组。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 6]  
下列参数严重影响重做日志文件的属性。

*  innodb\_log\_file\_size： 指定每个重做日志文件的大小。 设置的过大，在恢复时可能需要很多的时间。设置的过小，一个事务需要多次切换重做日志文件。还可能导致频繁的async checkpoint
 *  innodb\_log\_files\_in\_group： 指定日志文件组中重做文件的数量。
 *  innodb\_mirrored\_log\_grooups： 指定日志镜像文件组的数量，默认为1.
 *  innodb\_log\_group\_home\_dir

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

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

在第2章中已经提到，对于写入重做日志文件的操作不是直接写，而是先写入一个重做日志缓冲(redo log buffer)中，然后根据按照一定的条件写人日志文件。图3-3很好地表示了这个过程。

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 7]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70]: /images/20220210/e8fc82acd38e47978a1dde2e7ce9f170.png
[20190501100226400.png]: /images/20220210/c453e66621854e2c8dc0cc1a7d695e30.png
[2019050110030230.png]: /images/20220210/f591899099fd49c884ec1b919042478a.png
[20190501100701339.png]: /images/20220210/08e67b96f5434ce2bca09ae7eaea17b5.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 1]: /images/20220210/ae7bd410f5b44216b521ad6146b88fca.png
[20190501104642672.png]: /images/20220210/d54bd1df023841fc81706e5cae5a1588.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 2]: /images/20220210/6653f04024c84405a19339227e6ceaf6.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 3]: /images/20220210/14ff162b2a5e4a1486bb319e7dee673b.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 4]: /images/20220210/2374f89bfa214fc5801af442cb50af38.png
[20190501112845607.png]: /images/20220210/da73adf8d5164c35a48a23a0fca6ff19.png
[20190501112930912.png]: /images/20220210/8617b4fba9af452ab3d9421ca44f2b82.png
[20190501113018535.png]: /images/20220210/bf1937757d5f4a3aa6f4de3230b3dc2c.png
[20190501113251467.png]: /images/20220210/951cd802d0b44e30adb05be15560edf1.png
[20190501113405636.png]: /images/20220210/b283e1b2365b49a984d6e917dcb19715.png
[20190501114038465.png]: /images/20220210/f17ab77699d54d1a86620f32bba99f8e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 5]: /images/20220210/3765687cbb3648399613dbed438d0b35.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 6]: /images/20220210/2f499c50cf7142679d7404ce59cf6137.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dlaXhpbl80MTI2MjQ1Mw_size_16_color_FFFFFF_t_70 7]: /images/20220210/d3d7ce21ff05439a9434da6126e7ccc2.png