MySQL 物理文件组成

前言 麻雀虽小，五脏俱全。MySQL虽然以简单著称，但其内部结构并不简单。

本章从MySQL物理组成、逻辑组成，以及相关工具几个角度来介绍MySQL的总体架构组成，但愿可以让读者对MySQL有一个更全面深刻的了解。

MySQL物理文件组成

日志文件

一、错误日志：ErrorLog 错误日志记录了MyQLServer运行过程当中全部较为严重的警告和错误信息，以及MySQLServer每次启动和关闭的详细信息。

在默认状况下，系统记录错误日志的功能是关闭的，错误信息被输出到标准错误输出（stderr），

若是要开启系统记录错误日志的功能，须要在启动时开启-log-error选项。

错误日志的默认存放位置在数据目录下，以hostname.err命名。

可是可使用命令：--log-error[=file_name]，修改其存放目录和文件名。 

为了方便维护须要，有时候会但愿将错误日志中的内容作备份并从新开始记录，

这时候就能够利用MySQL的FLUSHLOGS命令来告诉MySQL备份旧日志文件并生成新的日志文件。备份文件名以“.old”结尾。

 二、二进制日志：BinaryLog&BinaryLogIndex 二进制日志，也就是咱们常说的binlog，

 也是MySQLServer中最为重要的日志之一。当咱们经过“--log-bin[=file_name]”打开了记录的功能以后，

 MySQL会将全部修改数据库数据的query以二进制形式记录到日志文件中。固然，日志中并不只限于query语句这么简单，还包括每一条query所执行的时间，所消耗的资源，以及相关的事务信息，因此binlog是事务安全的。 和错误日志同样，binlog记录功能一样须要

“--log-bin[=file_name]”参数的显式指定才能开启，若是未指定file_name，则会在数据目录下记录为mysql-bin.******（*表明0～9之间的某一个数字，来表示该日志的序号）。

 binlog还有其余一些附加选项参数： “--max_binlog_size”设置binlog的最大存储上限，当日志达到该上限时，MySQL会从新建立一个日志开始继续记录。不过偶尔也有超出该设置的binlog产生，通常都是由于在即将达到上限时，产生了一个较大的事务，

为了保证事务安全，MySQL不会将同一个事务分开记录到两个binlog中。

“--binlog-do-db=db_name”参数明确告诉MySQL，须要对某个（db_name）数据库记录binlog，  若是有了“--binlog-do-db=db_name”参数的显式指定，MySQL会忽略针对其余数据库执行的query，而仅仅记录针对指定数据库执行的query。 “--binlog-ignore-db=db_name”与“--binlog-do-db=db_name”彻底相反，它显式指定忽略某个（db_name）数据库的binlog记录，当指定了这个参数以后，MySQL会记录指定数据库之外全部的数据库的binlog。 

“--binlog-ignore-db=db_name”与“--binlog-do-db=db_name”两个参数有一个共同的概念须要你们理解清楚，  参数中的db_name不是指query语句更新的数据所在的数据库，而是执行query的时候当前所处的数据库。不论更新哪一个数据库的数据，MySQL仅仅比较当前链接所处的数据库（经过usedb_name切换后所在的数据库）与参数设置的数据库名， 而不会分析query语句所更新数据所在的数据库。 

mysql-bin.index文件（binarylogindex）的功能是记录全部BinaryLog的绝对路径，保证MySQL各类线程可以顺利的根据它找到全部须要的BinaryLog文件。

更新日志：

updatelog 更新日志是MySQL在较老的版本上使用的，其功能和binlog基本相似，只不过不是以二进制格式来记录而是以简单的文本格式记录内容。

自从MySQL增长了binlog功能以后，就不多使用更新日志了。

从版本5.0开始，MySQL已经再也不支持更新日志了。

查询日志：querylog 查询日志记录MySQL中全部的query，经过“--log[=fina_name]”来打开该功能。

因为记录了全部的query，包括全部的select，体积比较大，开启后对性能也有较大的影响，因此请你们慎用该功能。

通常只用于跟踪某些特殊的sql性能问题才会短暂打开该功能。默认的查询日志文件名为 hostname.log

慢查询日志：

   slowquerylog 顾名思义，慢查询日志中记录的是执行时间较长的query，也就是咱们常说的slowquery，

经过设--log-slow-queries[=file_name]来打开该功能并设置记录位置和文件名，默认文件名为hostname-slow.log，

默认目录也是数据目录。 慢查询日志采用的是简单的文本格式，能够经过各类文本编辑器查看其中的内容。

其中记录了语句执行的时刻，执行所消耗的时间，执行用户，链接主机等相关信息。

MySQL还提供了专门用来分析满查询日志的工具程序mysqlslowdump，用来帮助数据库管理人员解决可能存在的性能问题。

mysql> show global variables like '%slow%';

slow_query_log_file = /var/lib/mysql/slowsql.log  

Innodb的在线redo日志：

innodb redolog Innodb是一个事务安全的存储引擎，其事务安全性主要就是经过在线redo日志和记录在表空间中的undo信息来保证的。

redo日志中记录了Innodb所作的全部物理变动和事务信息，

经过redo日志和undo信息，Innodb保证了在任何状况下的事务安全性。

Innodb的redo日志一样默认存放在数据目录下，能够经过 

innodb_log_group_home_dir来更改设置日志的存放位置，

经过innodb_log_files_in_group设置日志的数量。

innodb_log_buffer_size = 2M  

innodb_log_file_size = 32M  

innodb_log_files_in_group = 3 

数据文件

  在MySQL中每个数据库都会在定义好（或者默认）的数据目录下存在一个以数据库名字命名的文件夹，用来存放该数据库中各类表数据文件。

  不一样的MySQL存储引擎有各自不一样的数据文件，存放位置也有区别。

  多数存储引擎的数据文件都存放在和MyISAM数据文件位置相同的目录下，可是每一个数据文件的扩展名却各不同。

  如MyISAM用“.MYD”做为扩展名，

  Innodb用“.ibd”，

  Archive用“.arc”，

  CSV用“.csv”，

  等等。 

一、“.frm”文件 与表相关的元数据（meta）信息都存放在“.frm”文件中，包括表结构的定义信息等。不管是什么存储引擎，每个表都会有一个以表名命名的“.frm”文件。全部的“.frm”文件都存放在所属数据库的文件夹下面。

二、“.MYD”文件“ .MYD”文件是MyISAM存储引擎专用，存放MyISAM表的数据。

每个MyISAM表都会有一个“.MYD”文件与之对应，一样存放于所属数据库的文件夹下，和“.frm”文件在一块儿。

三、“.MYI”文件 “.MYI”文件也是专属于MyISAM存储引擎的，主要存放MyISAM表的索引相关信息。对于MyISAM存储来讲，能够被cache的内容主要就是来源于“.MYI”文件中。每个MyISAM表对应一个“.MYI”文件，存放于位置和“.frm”以及“.MYD”同样。 

四、“.ibd”文件和ibdata文件 这两种文件都是存放Innodb数据的文件，之因此有两种文件来存放Innodb的数据（包括索引），

是由于 Innodb 的数据存储方式可以经过配置来决定是使用共享表空间存放存储数据，仍是独享表空间存放存储数据。

*********独享表空间存储方式

####独享表空间存储方式使用“.ibd”文件来存放数据，且每一个表一个“.ibd”文件，文件存放在和MyISAM数据相同的位置。####

*********共享存储表空间方式

若是选用共享存储表空间来存放数据，则会使用 ibdata 文件来存放，全部表共同使用一个（或者多个，可自行配置）ibdata文件。

ibdata文件能够经过 innodb_data_home_dir 和 innodb_data_file_path 两个参数共同配置组成，

innodb_data_home_dir配置数据存放的总目录，而innodb_data_file_path配置每个文件的名称。

固然，也能够不配置 innodb_data_home_dir 而直接在 innodb_data_file_path 参数配置的时候使用绝对路径来完成配置。

innodb_data_file_path 中能够一次配置多个 ibdata 文件。文件能够是指定大小，也能够是自动扩展的，

可是Innodb限制了仅仅只有最后一个ibdata文件可以配置成自动扩展类型。

当咱们须要添加新的ibdata文件的时候，只能添加在innodb_data_file_path配置的最后，并且必须重启MySQL才能完成ibdata的添加工做。

不过若是咱们使用独享表空间存储方式的话，就不会有这样的问题，

可是若是要使用裸设备的话，每一个表一个裸设备，可能形成裸设备数量很是大，

并且不太容易控制大小，实现比较困难，而共享表空间却不会有这个问题，容易控制裸设备数量。

我我的仍是更倾向于使用独享表空间存储方式。固然，两种方式各有利弊，看你们各自应用环境的侧重点在那里了。 

上面仅仅介绍了两种最经常使用存储引擎的数据文件，此外其余各类存储引擎都有各自的数据文件，读者朋友能够自行建立某个存储引擎的表作一个简单的测试，作更多的了解。

Replication 复制 相关文件：

一、master.info文件： master.info 文件存在于 Slave（从机）端的数据目录下，里面存放了该Slave的Master端的相关信息，包括Master的主机地址，链接用户，链接密码，链接端口，当前日志位置，已经读取到的日志位置等信息。 

二、relaylog 和 relaylogindex 

mysql-relay-bin.xxxxxn 文件用于存放Slave 端的 I/O 线程从Master端所读取到的BinaryLog信息，

而后由Slave端的SQL线程从该relaylog中读取并解析相应的日志信息，转化成Master所执行的SQL语句，而后在Slave端应用。 

mysql-relay-bin.index文件的功能相似于mysql-bin.index，一样是记录日志的存放位置的绝对路径，只不过他所记录的不是BinaryLog，而是RelayLog。 

三、relay-log.info文件： 

相似于master.info，它存放经过 Slave 的I/O线程写入到本地的relaylog的相关信息。供Slave端的SQL线程以及某些管理操做随时可以获取当前复制的相关信息。

其余文件： 

一、system config file 

MySQL的系统配置文件通常都是“my.cnf”，

Unix/Linux下默认存放在"/etc"目录下，Windows环境通常存放在“c:/windows”目录下面。

“my.cnf”文件中包含多种参数选项组（group），每一种参数组都经过中括号给定了固定的组名，

如“[mysqld]”组中包括了mysqld服务启动时候的初始化参数，

“[client]”组中包含着客户端工具程序能够读取的参数，此外还有其余针对于各个客户端软件的特定参数组，如mysql程序使用的“[mysql]”，mysqlchk使用的“[mysqlchk]”，等等。

若是读者朋友本身编写了某个客户端程序，也能够本身设定一个参数组名，将相关参数配置在里面，而后调用mysql客户端api程序中的参数读取api读取相关参数。 

二、pid file 

pidfile是mysqld应用程序在Unix/Linux环境下的一个进程文件，和许多其余Unix/Linux服务端程序同样，存放着本身的进程id。 

三、socket file 

socket文件也是在Unix/Linux环境下才有的，用户在Unix/Linux环境下客户端链接能够不经过TCP/IP网络而直接使用Unix Socket来链接 MySQL。

来自为知笔记(Wiz)