MySQL 架构组成--物理文件组成 for mysql6.7.13

http://hongge.blog.51cto.com/

1、MySQL Server 简介

什么是MySQL

MySQL 是由MySQL AB 公司（目前已经被SUN 公司收归麾下）自主研发的，目前IT 行业

最流行的开放源代码的数据库管理系统之一，它同时也是一个支持多线程高并发多用户的关

系型数据库管理系统。

MySQL 数据库以其简单高效可靠的特色，在最近短短几年的时间就从一个名不见经传的

数据库系统，变成一个在IT 行业几乎是无人不知的开源数据库管理系统。从

小型的web 网站，至大型的企业级应用，处处均可见其身影的存在。

MySQL 与其余数据库的简单比较

1）功能比较：

做为一个成熟的数据库管理系统，要知足各类各样的商业需求，功能确定是重点参考对象的。MySQL通过多年的改进和完善以后，已经基本具有了全部通用数据库管理系统所须要的相关功能。

MySQL 基本实现了ANSI SQL 92 的大部分标准，仅有少部分并不常常被使用的部分没有

实现。好比在字段类型支持方面，另外一个著名的开源数据库PostGreSQL 支持的类型是最完

整的，而Oracle 和其余一些商业数据库，好比DB二、Sybase 等，较MySQL 来讲也要相对少一些。在事务支持方面，虽然MySQL 本身的存储引擎并无提供，可是已经经过第三方插件式存储引擎Innodb 实现了SQL 92 标准所定义的四个事务隔离级别的所有。

不过在可编程支持方面，MySQL 和其余数据库相比还有必定的差距，虽然最新版的MySQL

已经开始提供一些简单的可编程支持，如开始支持Procedure，Function，Trigger 等，但

是所支持的功能还比较有限，和其余几大商用数据库管理系统相比，还存在较大的不足。如

Oracle 有强大的PL/SQL，SQL Server 有T-SQL，PostGreSQL 也有功能很完善的PL/PGSQL

的支持。

总体来讲， MySQL的功能彻底能够知足咱们的通用商业需求，提供足够强大的服务。并且无论是哪种数据库在功能方面都不敢声称本身比其余任何一款商用通用数据库管理系统都强，甚至都不敢声称可以本身拥有某一数据库产品的全部功能。由于每一款数据库管理系统都有起自身的优点，也有起自身的限制，这只能表明每一款产品所倾向的方向不同。

2）易用性比较：

从系统易用性方面来比较，每个使用过MySQL 的用户都可以明显地感受出MySQL 在这方面与其余通用数据库管理系统之间的优点所在。尤为是相对于一些大型的商业数据库管理系统如Oracle、DB2 以及Sybase 来讲，对于普通用户来讲，操做的难易程度明显不处于一

个级别。MySQL 一直都奉行简单易用的原则，也正是靠这一特性，吸引了大量的初级数据库用户最终选择了MySQL。

从安装方面来讲，MySQL 安装包大小仅仅只有100MB 左右，这与几大商业数据库彻底不在一个数量级。安装难易程度也要比Oracle 等商业数据库简单不少，不管是经过已经编译好

的二进制分发包仍是源码编译安装，都很是简单。

再从数据库建立来比较，MySQL 仅仅只须要一个简单的CREATE DATABASE 命令，便可在瞬间完成建库的动做，而Oracle 数据库与之相比，建立一个数据库简直就是一个很是庞大的工程。固然，两者数据库的概念存在必定差异。

3）性能比较

性能方面，一直是MySQL 引觉得自豪的一个特色。在权威的第三方评测机构屡次测试较量各类数据库TPCC 值的过程当中，MySQL 一直都有很是优异的表现，并且在其余全部商用的通用数据库管理系统中，仅仅只有Oracle 数据库可以与其一较高下。

4）可靠性

关于可靠性的比较，MySQL 也有很是优异的表现，从当前最火的Facebook 这样大型的网站都是使用MySQL 数据库，就能够看出，MySQL 在稳定可靠性方面，并且排在全球前10 位的大型网站里面，大部分都有部分业务是运行在MySQL数据库环境上，如Yahoo，Google 等。

总的来讲，MySQL 数据库在发展过程当中一直有本身的三个原则：简单、高效、可靠。

MySQL 的主要适用场景

MySQL是目前最为流行的开源数据库管理系统软件了。那么MySQL 主要用于什么场景下

1）Web 网站系统

Web 站点，是MySQL 最大的客户群，MySQL 之因此能成为Web 站点开发者们最青睐的数据库管理系统，是由于MySQL 数据库的安装配置都很是简单，使用过程当中的维护也不像不少大型商业数据库管理系统那么复杂，并且性能出色。还有一个很是重要的缘由就是MySQL 是开放源代码的，彻底能够无偿使用。

2）日志记录系统

MySQL 数据库的插入和查询性能都很是的高效，若是设计地较好，在使用MyISAM 存储引擎的时候，二者能够作到互不锁定，达到很高的并发性能。因此，对须要大量的插入和查询日志记录的系统来讲，MySQL 是很是不错的选择。好比处理用户的登陆日志，操做日志等是很是适合的应用场景。

3）数据仓库系统

随着如今数据仓库数据量的飞速增加，咱们须要的存储空间愈来愈大。数据量的不断增加，使数据的统计分析变得愈来愈低效，也愈来愈困难。怎么办？这里有几个主要的解决思路，一个是采用昂贵的高性能主机以提升计算性能，用高端存储设备提升I/O 性能，效果理想，可是成本很是高；第二个就是经过将数据复制到多台使用大容量硬盘的廉价pc server上，以提升总体计算性能和I/O 能力，效果尚可，存储空间有必定限制，成本低廉；第三个，经过将数据水平拆分，使用多台廉价的pc server 和本地磁盘来存放数据，每台机器上面都只有全部数据的一部分，解决了数据量的问题，全部pc server 一块儿并行计算，也解决了计算能力问题，经过中间代理程序调配各台机器的运算任务，既能够解决计算性能问题又能够解决I/O 性能问题，成本也很低廉。在上面的三个方案中，第二和第三个的实现，MySQL 都

有较大的优点。经过MySQL 的简单复制功能，能够很好的将数据从一台主机复制到另一台，

不只仅在局域网内能够复制，在广域网一样能够。固然，其余的数据库一样也能够作到，不是只有MySQL 有这样的功能。可是MySQL是免费的，其余数据库大多都是按照主机数量或者cpu 数量来收费，当咱们使用大量的pc server 的时候，license 费用至关惊人。第一个方案，基本上全部数据库系统都可以实现，可是其高昂的成本并非每个公司都可以承担的。

2、MySQL 架构组成

Mysql物理文件组成：

1）日志文件：主要包含：错误日志、查询日志、慢查询日志、事务日志、二进制日志

日志是mysql数据库的重要组成部分。日志文件中记录着mysql数据库运行期间发生的变化；也就是说用来记录mysql数据库的客户端链接情况、SQL语句的执行状况和错误信息等。当数据库遭到意外的损坏时，能够经过日志查看文件出错的缘由，而且能够经过日志文件进行数据恢复。

一、错误日志：Error Log

在mysql数据库中，错误日志功能是默认开启的。默认状况下，错误日志存储在mysql数据库的数据目录中。错误日志文件一般的名称为hostname.err。其中，hostname表示服务器主机名。

错误日志信息能够本身进行配置的，错误日志所记录的信息是能够经过log-error和log-warnings来定义的，其中log-error是定义是否启用错误日志的功能和错误日志的存储位置，log-warnings是定义是否将警告信息也定义至错误日志中。默认状况下错误日志大概记录如下几个方面的信息：服务器启动和关闭过程当中的信息（未必是错误信息，如mysql如何启动InnoDB的表空间文件的、如何初始化本身的存储引擎的等等）、服务器运行过程当中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器进程时产生的信息

注1：MySQL有不少系统变量能够设置，系统变量设置不一样，会致使系统运行状态的不一样。所以mysql提供两组命令，分别查看系统设置和运行状态。
一、查看系统设置：
SHOW [GLOBAL | SESSION] VARIABLES [like_or_where] 
SHOW VARIABLES： shows the values of MySQL system variables. 
二、运行状态：
SHOW [GLOBAL | SESSION] STATUS [like_or_where] 
SHOW STATUS： provides server status information.

如何修改系统配置

方法1：配置文件设置my.cnf

如：binlog_cache_size = 1M

方法2：set global binlog_cache_size = 1048576;

注2：查看mysql的版本

或

或

通常而言，日志级别的定义没有会话变量都只是在全局级别下进行定义

错误日志的状态：

其中

log_error定义为错误日志文件路径

log_error_verbosity:

The MySQL error log has received some attention in MySQL 5.7, with a new setting called log_error_verbosity.

There are three possible values, as documented in the manual:

Verbosity Value	Message Types Logged
1	Errors only
2	Errors and warnings
3	Errors, warnings, and notes (default)

更改错误日志位置可使用log-error来设置形式以下

#vi /etc/my.cnf

log-error = /usr/local/mysql/data/mysqld.err

查看mysql错误日志：

#tail /usr/local/mysql/data/mysqld.err

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

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

删除错误日志：

在mysql5.5.7以前：数据库管理员能够删除很长时间以前的错误日志，以保证mysql服务器上的硬盘空间。mysql数据库中，可使用mysqladmin命令开启新的错误日志。mysqladmin命令的语法以下：mysqladmin –u root –p flush-logs也能够登陆mysql数据库中使用FLUSH LOGS语句来开启新的错误日志。

在mysql5.5.7以后：服务器将关闭此项功能。只能使用重命名原来的错误日志文件，手动冲洗日志建立一个新的：方式以下：

更多信息请查阅官方文档：http://dev.mysql.com/doc/refman/5.5/en/error-log.html

http://dev.mysql.com/doc/refman/5.6/en/error-log.html

http://dev.mysql.com/doc/refman/5.7/en/error-log.html

二、二进制日志：Binary Log & Binary Log Index

二进制日志，也就是咱们常说的binlog，也是MySQL Server 中最为重要的日志之一，主要用于记录修改数据或有可能引发数据改变的mysql语句，而且记录了语句发生时间、执行时长、操做的数据等等。因此说经过二进制日志能够查询mysql数据库中进行了哪些变化。通常大小体积上限为1G。

当咱们经过“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 的最大存储上限，通常设置为512M或1G,通常不能超过1G当日志达到该上限时，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 仅仅比较当前链接所处的数据库（经过use db_name 切换后所在的数据库）与参数设置的数据库名，而不会分析query 语句所更新数据所在的数据库。

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

binlog_cache_size =32768   #默认值32768 binlog_cache_size ：一个事务，在没有提交（uncommitted）的时候，产生的日志，记录到Cache中；等到事务提交（committed）须要提交的时候，则把日志持久化到磁盘。通常来讲，若是咱们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。可是若是咱们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，咱们能够经过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache因为内存大小不够而使用临时文件（binlog_cache_disk_use）来缓存了。

binlog_stmt_cache_size= 32768 #当非事务语句使用二进制日志缓存，可是超出binlog_stmt_cache_size时，使用一个临时文件来存放这些语句。

概念解释：

事务表支持将批处理当作一个完整的任务统一提交或回滚，即对包含在事务中的多条语句要么全执行，要么所有不执行
非事务表则不支持此种操做，批处理中的语句若是遇到错误，在错误前的语句执行成功，以后的则不执行。

log_bin = mysql-bin#指定binlog的位置，默认在数据目录下。

binlog-format= {ROW|STATEMENT|MIXED}#指定二进制日志的类型，默认为MIXED。

概念解释：mysql复制主要有三种方式：基于SQL语句的复制(statement-based replication, SBR)，基于行的复制(row-based replication, RBR)，混合模式复制(mixed-based replication, MBR)。对应的，binlog的格式也有三种：STATEMENT，ROW，MIXED。

① STATEMENT模式（SBR）

每一条会修改数据的sql语句会记录到binlog中。优势是并不须要记录每一行的数据变化，减小了binlog日志量，节约IO，提升性能。缺点是在某些状况下会致使master-slave中的数据不一致(如sleep()函数， last_insert_id()，以及user-defined functions(udf)等会出现问题)

② ROW模式（RBR）

不记录每条sql语句的信息，仅需记录哪条数据被修改了，修改为什么样了。缺点是会产生大量的日志，让日志暴涨。

③ MIXED模式（MBR）

以上两种模式的混合使用，通常的复制使用STATEMENT模式保存binlog，对于STATEMENT模式没法复制的操做使用ROW模式保存binlog，MySQL会根据执行的SQL语句选择日志保存方式。即交替使用行和语句、由mysql服务器自行判断。

其中基于行的定义格式数据量会大一些可是能够保证数据的精确性

sync_binlog = 10#设定多久同步一次二进制日志至磁盘文件中，0表示不一样步，任何正数值都表示对二进制每多少次写操做以后同步一次。当autocommit的值为1时，每条语句的执行都会引发二进制日志同步，不然，每一个事务的提交会引发二进制日志同步

max_binlog_cache_size= {4096 .. 18446744073709547520}      #二进制日志缓存空间大小，5.5.9及之后的版本仅应用于事务缓存，其上限由max_binlog_stmt_cache_size决定。

max_binlog_stmt_cache_size= {4096 .. 18446744073709547520}    #二进制日志缓存空间大小，5.5.9及之后的版本仅应用于事务缓存

expire_log_days ={0..99}    #设定二进制日志的过时天数，超出此天数的二进制日志文件将被自动删除。默认为0，表示不启用过时自动删除功能。若是启用此功能，自动删除工做一般发生在MySQL启动时或FLUSH日志时。

经过编辑my.cnf中的log-bin选项能够开启二进制日志；形式以下：

log-bin [=DIR/[filename]]

其中，DIR参数指定二进制文件的存储路径；filename参数指定二级制文件的文件名，其形式为filename.number，number的形式为00000一、000002等。每次重启mysql服务或运行mysql> flush logs;都会生成一个新的二进制日志文件，这些日志文件的number会不断地递增。除了生成上述的文件外还会生成一个名为filename.index的文件。这个文件中存储全部二进制日志文件的清单又称为二进制文件的索引

查看二进制日志：

二进制日志的定义方式为二进制格式；使用此格式能够存储更多的信息，而且可使写入二进制日志的效率更高。可是不能直接使用查看命令打开并查看二进制日志。

当前使用的二进制文件及所处位置

查看当前二进制文件的信息：

查看二进制日志信息的命令：

语法格式：SHOW BINLOG EVENTS[IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

#查看全部的二进制信息

mysql> show binlog events\G;

#查看指定日志的二进制信息

mysql> show binlog events in 'mysql-bin.000016'\G;

#从指定的事件位置开始

mysql> show binlog events  in 'mysql-bin.000016' from 727;

注：二进制日志的记录位置：一般为上一个事件执行结束时间的位置

#指定偏移量(不是语句，是事件)

mysql> show binlog events in 'mysql-bin.000017' from 154 limit 3;

命令行下查看二进制日志：

因为没法使用cat等方式直接打开并查看二进制日志；因此必须使用mysqlbinlog命令。可是当正在执行mysql读写操做时建议不要使用此打开正在使用的二进制日志文件；若非要打开可flush logs。mysqlbinlog命令的使用方式：

/*!50530 SET @@SESSION.PSEUDO_SLAVE_MODE=1*/;

/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;

DELIMITER /*!*/;

# at 219 #事件开始处

#160829 0:23:22 server id 1 end_log_pos 296 CRC32 0xc81eb3b9 Query thread_id=2 exec_time=0 error_code=0

#160829 0:23:22年月日的简写方式；end_log_pos事件结束处；thread_id=2 哪一个会话线程建立的此语句；exec_time=0 执行时长单位为秒；error_code=0 错误代码0表示没有

SET TIMESTAMP=1472401402/*!*/;

SET @@session.pseudo_thread_id=2/*!*/;

SET @@session.foreign_key_checks=1, @@session.sql_auto_is_null=0, @@session.unique_checks=1, @@session.autocommit=1/*!*/;

SET @@session.sql_mode=1075838976/*!*/;

SET @@session.auto_increment_increment=1, @@session.auto_increment_offset=1/*!*/;

/*!\C utf8 *//*!*/;

SET @@session.character_set_client=33,@@session.collation_connection=33,@@session.collation_server=33/*!*/;

SET @@session.lc_time_names=0/*!*/;

SET @@session.collation_database=DEFAULT/*!*/;

BEGIN

/*!*/;

# at 296

#160829 0:23:22 server id 1 end_log_pos 393 CRC32 0xbc94b235 Query thread_id=2 exec_time=0 error_code=0

use `db2`/*!*/;

SET TIMESTAMP=1472401402/*!*/;

insert into tb1 values(3)

删除二进制日志信息：

二进制日志会记录大量的信息（其中包含一些无用的信息）。若是很长时间不清理二进制日志，将会浪费不少的磁盘空间。可是，删除以后可能致使数据库崩溃时没法进行恢复，因此若要删除二进制日志首先将其和数据库备份一份，其中也只能删除备份前的二进制日志，新产生的日志信息不可删。也不可在关闭mysql服务器以后直接删除由于这样可能会给数据库带来错误的。若非要删除二进制日志须要作以下操做：导出备份数据库和二进制日志文件进行压缩归档存储。删除二进制文件的方法以下：

方法1：根据文件或时间点来删除二进制日志：

语法形式：

mysql> PURGE { BINARY | MASTER } LOGS {TO 'log_name' | BEFORE datetime_expr }

其中TO 'log_name'表示把这个文件以前的其余文件都删除掉，也可以使用BEFORE datetime_expr指定把哪一个时间以前的二进制文件删除了。

或者用ls查看

方法2：删除全部的二进制日志（慎用）：

使用RESET MASTER语句能够删除全部的二进制日志。该语句的形式以下：

不建议在生产环境下使用此操做；删除全部的二进制日志后，Mysql将会从新建立新的二进制日志。新二进制日志的编号从000001开始。

三、事务日志(或称redo日志)

事务日志（InnoDB特有的日志）能够帮助提升事务的效率。使用事务日志，存储引擎在修改表的数据时只须要修改其内存拷贝，再把修改行为记录到持久在硬盘上的事务日志中，而不用每次都将修改的数据自己持久到磁盘。事务日志采用追加的方式，所以写日志的操做是磁盘上一小块区域内的顺序I/O，而不像随机I/O须要在磁盘的多个地方移动磁头，因此采用事务日志的方式相对来讲要快得多。事务日志持久之后，内存中被修改的数据在后台能够慢慢的刷回到磁盘。目前大多数的存储引擎都是这样实现的。

若是数据的修改已经记录到事务日志并持久化，但数据自己尚未写回磁盘，此时系统崩溃，存储引擎在重启时可以自动恢复这部分修改的数据。具备的恢复方式则视存储引擎而定。

通常状况下，mysql会默认提供多种存储引擎,你能够经过下面的查看:
查看你的mysql如今已提供什么存储引擎:
mysql> show engines;
看你的mysql当前默认的存储引擎:
mysql> show variables like '%storage_engine%';
你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎):
mysql> show create table 表名;

注：

create table 库名.表名 engine = innodb;
这样就能够将表的引擎变动为innodb引擎了。
也能够在建立表以后经过下面语句来变动：
alter table库名.表名engine =innodb;

查看事务日志的定义：

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

显示结果：

| innodb_flush_log_at_timeout | 1 |

| innodb_flush_log_at_trx_commit | 1 #在事务提交时innodb是否同步日志从缓冲区到文件中，当这个值为1（默认值）之时，在每一个事务提交时，日志缓冲被写到日志文件，对日志文件作到磁盘操做的刷新，性能会不好形成大量的磁盘I/O但这种方式最安全；若是设为2,每次提交事务都会写日志，但并不会执行刷的操做。每秒定时会刷到日志文件。要注意的是，并不能保证100%每秒必定都会刷到磁盘，这要取决于进程的调度。每次事务提交的时候将数据写入事务日志，而这里的写入仅是调用了文件系统的写入操做，而文件系统是有 缓存的，因此这个写入并不能保证数据已经写入到物理磁盘。设置为0，日志缓冲每秒一次地被写到日志文件，而且对日志文件作到磁盘操做的刷新，可是在一个事务提交不作任何操做。

注：刷写的概念

刷写实际上是两个操做，刷（flush）和写（write），区分这两个概念是很重要的。在大多数的操做系统中，把Innodb的log buffer（内存）写入日志（调用系统调用write），只是简单的把数据移到操做系统缓存中，操做系统缓存一样指的是内存。并无实际的持久化数据。

因此，一般设为0和2的时候，在崩溃或断电的时候会丢失最后一秒的数据，由于这个时候数据只是存在于操做系统缓存。之因此说“一般”，可能会有丢失不仅1秒的数据的状况，好比说执行flush操做的时候阻塞了。

总结

设为1固然是最安全的，但性能页是最差的（相对其余两个参数而言，但不是不能接受）。若是对数据一致性和完整性要求不高，彻底能够设为2,若是只最求性能，例如高并发写的日志服务器，设为0来得到更高性能

|

| innodb_locks_unsafe_for_binlog | OFF |

| innodb_log_buffer_size | 16777216 |

| innodb_log_checksums | ON |

| innodb_log_compressed_pages | ON |

| innodb_log_file_size | 50331648 #日志文件大小 |

| innodb_log_files_in_group | 2 # DB中设置几组事务日志，默认是2 |

| innodb_log_group_home_dir | ./ #定义innodb事务日志组的位置,此位置设置默认为MySQL的datadir  |

每一个事务日志都是大小为50兆的文件（不一样版本的mysql有差别）：

在mysql中默认以ib_logfile0,ib_logfile1名称存在

四、慢查询日志：slow query log

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

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

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

慢查询日志的做用：

慢查询日志是用来记录执行时间超过指定时间的查询语句。经过慢查询日志，能够查找出哪些查询语句的执行效率很低，以便进行优化。通常建议开启，它对服务器性能的影响微乎其微，可是能够记录mysql服务器上执行了很长时间的查询语句。能够帮助咱们定位性能问题的。MySQL 还提供了专门用来分析满查询日志的工具程序mysqldumpslow，用来帮助数据库管理人员解决可能存在的性能问题。

查看慢查询日志的定义：

启动和设置慢查询日志：

方法1：经过配置文件my.cnf开启慢查询日志：

注：在不一样的mysql版本中，开启慢查询日志参数不太同样，不过均可以经过 show variables like "%slow%" 和show variables like "%long%"查看出来。

其中：

slow_query_log： off关闭状态  on开启状态
slow_query_log_file  慢查询日志存放地点

long_query_time选项来设置一个时间值，时间以秒为单位，能够精确到微秒。若是查询时间超过了这个时间值（默认为10秒），这个查询语句将被记录到慢查询日志中, 设置为0的话表示记录全部的查询。

slow_launch_time   表示若是创建线程花费了比这个值更长的时间,slow_launch_threads 计数器将增长

注：若是不指定存储路径，慢查询日志默认存储到mysql数据库的数据文件下，若是不指定文件名，默认文件名为hostname-slow.log

修改my.cnf文件：

重启mysqld服务

再次查询慢查询日志定义：

方法2：经过登陆mysql服务器直接定义，方式以下：

mysql>set global slow_query_log=1;  #开启慢查询日志

Query OK, 0 rowsaffected (0.35 sec)

mysql>set session long_query_time=0.0001; #更改时间（当前session中，退出则重置）

Query OK, 0 rowsaffected (0.00 sec)

mysql>set global long_query_time=0.0001; #更改时间（全局中，重启服务则重置）

mysql> SHOW VARIABLES LIKE 'long%';  #查询定义时间

查看慢查询日志

mysql> use mysql

mysql> selectuser,host from user where user="root";

或用系统查看文件内容命令如cat直接查看慢日志文件

第一行表示记录日志时的时间。其格式是 YYYY-MM-DD HH:MM:SS。咱们能够看出上面的查询记录于 2016 年 8 月 29 日下午 15:47：24 - 注意：这个是服务器时间.

MySql 用户、服务器以及主机名第三行表示总的查询时间、锁定时间、"发送"或者返回的行数

Query_time: 0.000304 表示用了0.000304秒

Lock_time: 0.000128 表示锁了0.000128秒

Rows_sent: 4 表示返回4行

Rows_examined: 4 表示一共查了4行

SET timestamp=UNIXTIME; 这是查询实际发生的时间

何将其变成一个有用的时间，将 Unix 时间转成一个可读的时间，可使用 date –d@日志中的时间戳

以看到查询进行的同时记录了该日志 ，可是对于一台超负载的服务器经常并不是如此。所以记住：SET timestamp= value 才是实际的查询的执行时间。

慢查询分析mysqldumpslow

们能够经过打开log文件查看得知哪些SQL执行效率低下。从日志中，能够发现查询时间超过long_query_time时间的query为慢查询，而小于long_query_time时间的没有出如今此日志中。

若是慢查询日志中记录内容不少，可使用mysqldumpslow工具（MySQL客户端安装自带）来对慢查询日志进行分类汇总。mysqldumpslow对日志文件进行了分类汇总，显示汇总后摘要结果

进入log的存放目录，运行

[root@localhost data]# mysqldumpslow mysqld-slow.log

注：

mysqldumpslow -s c -t 10 /database/mysql/slow-query.log                     

这会输出记录次数最多的10条SQL语句，其中：

-s, 是表示按照何种方式排序，c、t、l、r分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒序；

-t, 是top n的意思，即为返回前面多少条的数据；

-g, 后边能够写一个正则匹配模式，大小写不敏感的；

例如：

/path/mysqldumpslow -s r -t 10 /database/mysql/slow-log                                

获得返回记录集最多的10个查询。

/path/mysqldumpslow -s t -t 10 -g “left join” /database/mysql/slow-log      

获得按照时间排序的前10条里面含有左链接的查询语句。

2）数据文据

在MySQL 中每个数据库都会在定义好（或者默认）的数据目录下存在一个以数据库名字命名的文件夹，用来存放该数据库中各类表数据文件。不一样的MySQL 存储引擎有各自不一样的数据文件。如MyISAM 用“.MYD”做为扩展名，Innodb 用“.ibd”，Archive 用“.arc”，CSV 用“.csv”，等等。

如何查看你的mysql如今已提供什么存储引擎:
mysql> show engines;
看你的mysql当前默认的存储引擎:
mysql> show variables like '%storage_engine%';

你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎):
mysql> show create table 表名;

注：

create table 库名.表名 engine = innodb; 这样就能够将表的引擎变动为innodb引擎了。

登陆mysql，建立一个数据库如testdb，并在数据库中建立一个表，以下图所示：

查看数据库所在目录会发现数据目录下存在一个以数据库名字命名的文件夹

查看testdb目录的文件列表

从上图能够看出表使用的是innodb存储引擎。

以myisam存储引擎建立一个测试表tb2

查看数据库目录

注：修改mysql的默认存储引擎

一、查看mysql存储引擎命令，在mysql>提示符下搞入show engines;字段 Support为:Default表示默认存储引擎
二、设置InnoDB为默认引擎：在配置文件my.cnf中的 [mysqld] 下面加入default-storage-engine=INNODB 一句
三、重启mysql服务器：mysqladmin -u root -p shutdown或者service mysqld restart 登陆mysql数据库，

一、“.frm”文件

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

MyISAM数据库表文件：.MYD文件：表数据文件；.MYI文件：索引文件

二、“.MYD”文件

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

三、“.MYI”文件

“.MYI”文件也是专属于MyISAM 存储引擎的，主要存放MyISAM 表的索引相关信息。对于MyISAM 存储来讲，能够被cache 的内容主要就是来源于“.MYI”文件中。每个MyISAM

表对应一个“.MYI”文件，存放于位置和“.frm”以及“.MYD”同样。

InnoDB采用表空间（tablespace）来管理数据，存储表数据和索引。

.ibd文件：单表表空间文件，每一个表使用一个表空间文件（file per table），存放用户数据库表数据和索引。

InnoDB共享表空间（即InnoDB文件集，ib-file set）：ibdata一、ibdata2等，存储InnoDB系统信息和用户数据库表数据和索引，全部表共用。

四、“.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_file_path 中能够一次配置多个ibdata 文件。文件能够是指定大小，也能够是自动扩展的，可是Innodb 限制了仅仅只有最后一个ibdata 文件可以配置成自动扩展类型。当咱们须要添加新的ibdata 文件的时候，只能添加在innodb_data_file_path配置的最后，并且必须重启MySQL 才能完成ibdata 的添加工做。不过若是咱们使用独享表空间存储方式的话，就不会有这样的问题。

总结：

共享表空间以及独占表空间都是针对数据的存储方式而言的。

共享表空间:  某一个数据库的全部的表数据，索引文件所有放在一个文件中。

独占表空间:  每个表都将会生成以独立的文件方式来进行存储，每个表都有一个.frm表描述文件，还有一个.ibd文件。 其中这个文件包括了单独一个表的数据内容以及索引内容。

二者之间的优缺点

共享表空间：
优势：
能够放表空间分红多个文件存放到各个磁盘上。数据和文件放在一块儿方便管理。
缺点：
全部的数据和索引存放到一个文件中，多个表及索引在表空间中混合存储，这样对于一个表作了大量删除操做后表空间中将会有大量的空隙，特别是对于统计分析，日值系统这类应用最不适合用共享表空间。

独立表空间：

优势：
1．每一个表都有自已独立的表空间。
2．每一个表的数据和索引都会存在自已的表空间中。
3．能够实现单表在不一样的数据库中移动。
4．空间能够回收
a)  Drop table操做自动回收表空间，若是对于统计分析或是日值表，删除大量数据后能够经过:alter table TableName engine=innodb;回缩不用的空间。
b)对于使用独立表空间的表，无论怎么删除，表空间的碎片不会太严重的影响性能，并且还有机会处理。
缺点：
单表增长过大，如超过100个G。

相比较之下，使用独占表空间的效率以及性能会更高一点

查看当前数据库的表空间管理类型

ON表明独立表空间管理，OFF表明共享表空间管理；（查看单表的表空间管理方式，须要查看每一个表是否有单独的数据文件）

Innodb共享表空间配置：

修改my.cnf文件：

参数解释：

innodb_data_home_dir = "/path/" 数据库文件所存放的目录

innodb_log_group_home_dir = "/path/" 日志存放目录

innodb_data_file_path=ibdata1:10M:autoextend 设置一个可扩展大小的尺寸为10MB的数据文件（共享数据文件），名为ibdata1。没有给出文件的位置，因此默认的是在MySQL的数据目录内。

innodb_file_per_table=1｜0 //1为使用独占表空间，0 为使用共享表空间

注：InnoDB不建立目录，因此在启动服务器以前请确认”所配置的路径目录”的确存在。

重启mysqld服务

mysqld启动失败,查看错误日志

#tail -20 /usr/local/mysql/data/mysqld.err

显示内容以下：

注：不一样版本的mysql报错略有不一样，注意看错误日志的内容。

从错误日志中显示能够看出

在/etc/my.cnf文件中设置6400页而当前ibdata1为768页

须要计算768/64=12
修改配置为

重启mysqld服务

启动mysql，成功！

注：计算公式：64pages至关于1M，1page是16KB

若是不清楚默认文件page大小，能够先 du -h ibdata1 查看下，再去设置；

这说明mysql5.7.13中ibdata初始化为12M

登陆mysql执行mysql> show variables like '%innodb_file_per_table%';

这时新建的表就会使用共享表空间了。

建立一个数据库testdb并新建一个表

向表中插入若干行数据

这里定义一个存储过程向表中插入100000行数据

调用存储过程

查看表中行数：

如何查看表在表空间占用状况：

方法1：对INNODB，你能够直接用命令show table status查看某个表的表空间占用状况。

方法2：

若是想知道MySQL数据库中每一个表占用的空间、表记录的行数的话，能够打开MySQL的 information_schema 数据库。在该库中有一个 TABLES 表，这个表主要字段分别是：

TABLE_SCHEMA : 数据库名
TABLE_NAME：表名
ENGINE：所使用的存储引擎
TABLE_ROWS：记录数
DATA_LENGTH：数据大小
INDEX_LENGTH：索引大小

3、Replication相关文件：

1）master.info 文件：

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

2）relay log 和relay log index

mysql-relay-bin.xxxxxn 文件用于存放Slave 端的I/O 线程从Master 端所读取到的Binary Log 信息，而后由Slave 端的SQL 线程从该relay log 中读取并解析相应的日志信息，转化成Master 所执行的SQL 语句，而后在Slave 端应用。

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

3）relay-log.info 文件：

相似于master.info，它存放经过Slave 的I/O 线程写入到本地的relay log 的相关信

息。供Slave 端的SQL 线程以及某些管理操做随时可以获取当前复制的相关信息。

4、其余文件：

1）system config file

MySQL 的系统配置文件通常都是my.cnf，默认存放在"/etc"目录下，my.cnf文件中包含多种参数选项组（group），每一种参数组都经过中括号给定了固定的组名，如“[mysqld]”组中包括了mysqld服务启动时候的初始化参数，“[client]”组中包含着客户端工具程序能够读取的参数。

2）pid file

pid file 是mysqld 应用程序在Unix/Linux 环境下的一个进程文件，和许多其余

Unix/Linux 服务端程序同样，存放着本身的进程id。

3）socket file

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

mysql有两种链接方式，经常使用的通常是tcp
mysql –h mysql主机ip -uroot -pxxx
mysql -S /path /mysql.sock

注：采用unix socket链接方式，比用tcp的方式更快，但只适用于mysql和应用同在一台PC上。

http://hongge.blog.51cto.com/