共计 4593 个字符,预计需要花费 12 分钟才能阅读完成。
mysql 的物理文件这里次要讲:日志文件、数据库文件和配置文件
1.Mysql 日志文件
mysql 的日志文件次要有 5 种:谬误日志、二进制日志、事务日志、慢查问日志、查问日志。
1.1 谬误日志(Error Log)
文件名:*.err
默认状况下谬误日志大略记录以下几个方面的信息:
- 服务器启动和敞开过程中的信息(未必是错误信息,如 mysql 如何启动 InnoDB 的表空间文件的、如何初始化本人的存储引擎的等等。
- 服务器运行过程中的错误信息、事件调度器运行一个事件时产生的信息、在从服务器上启动服务器过程时产生的 - 信息。
留神:这里并不会记录 sql 执行谬误的日志。
# 查问谬误日志地位命令
show global variables like '%log_error%';
1.2 事务日志(InnoDB redo Log & undo Log)
事务日志是 InnoDB 独有的日志。事务日志又分为:重做日志(redo Log)、回滚日志(undo Log)
应用事务日志,存储引擎在批改表的数据时只须要批改其 内存拷贝 ,再把批改行为记录到硬盘上长久的事务日志中,而不必每次都将批改的数据自身长久到磁盘。
事务日志采纳追加的形式,因而写日志的操作是磁盘上一小块区域内的程序 I /O,而不像随机 I / O 须要在磁盘的多个中央挪动磁头,所以采纳事务日志的形式相对来说要快得多。
事务日志长久当前,内存中被批改的数据在后盾能够缓缓的刷回到磁盘 。目前大多数的存储引擎都是这样实现的。
事务具体执行流程:https://www.cnblogs.com/maypattis/p/5628355.html
- 重做日志 (redo Log)
文件名:*.ib_logfile0
redo log 是指在回放日志的时候把曾经 COMMIT 的事务重做一遍,对于没有 COMMIT 的事务依照 abort 解决,不进行任何操作。Redo 日志记录了 InnoDB 所做的所有物理变更和事务信息 - 回滚日志 (undo Log)
文件名:*.ibdata
undo log 是把所有没有 COMMIT 的事务回滚到事务开始前的状态,零碎解体时,可能有些事务还没有 COMMIT,在零碎复原时,这些没有 COMMIT 的事务就须要借助 undo log 来进行回滚。
Innodb 存储引擎可将所有数据寄存于 ibdata* 的共享表空间,也可将每张表寄存于独立的.ibd 文件的独立表空间。
-- 查看事务日志:show engine innodb statusG;
-- 查看日志文件设置状态
show variables like 'innodb_%';
-- innodb_log_files_in_group DB 中设置几组事务日志,默认是 2
-- innodb_log_group_home_dir 事务日志寄存目录;不设置,ib_logfile0... 存在在数据文件目录下
1.3 二进制日志(Binary Log)
二进制日志,也就是咱们常说的 binlog。二进制日志记录了 MySQL 所有批改数据库的操作,而后以二进制的模式记录日志在日志文件中,其中还包含没调语句所执行的工夫和耗费的资源,以及相干的事务信息。
作用:
- 记录 sql 操作(数据备份)
- 增量数据备份及复原
- sql 主从复制
阐明:
- 默认状况下二进制日志是敞开的,然而在宝塔中是默认开启的。
- 因为记录的是所有 sql 的执行记录,所以产生的日志文件的量会很大,这个状况下就要进行日志文件的定时挪到备份服务器或者进行定时删除。
# 查问二进制日志开启等状况
show global variables like '%log_bin%';
1.4 慢查问日志(Show Query Log)
文件名:*show.log(默认目录是 data 目录下)
慢查问日志中记录的是执行工夫较长的 query,也就是咱们常说的 slow query。
业余一点:慢查问日志是值所有 SQL 执行的理论超过 long_query_time 变量的语句和达到 min_examined_row_limit 条举例的语句。用户能够针对这部分语句性能调优。慢查问日志通过设置 log-slow_queries[=file_name]选项开启后,将记录日志所在的路劲和名称。
留神: 慢查问 对事务的执行是不记录的。如果测试的话,请应用 select sleep(60); 这样的语句来测试
-- 查看慢查问信息
show variables like "%slow%" ;
-- log_slow_queries off 示意“慢查问”是“敞开的状态”-- slow_launch_time 2 示意“查问工夫超过 2 秒就记录到慢查问日志中”;-- slow_queries_log off 示意慢查问日志开关是关着的
-- slow_query_log_file "门路" 示意慢查问日志寄存残缺门路
-- 查看 long_query_time(最大等待时间, 或者慢查问工夫)设置工夫
-- 留神和 slow_launch_time 的区别
show variables like "%long%"
-- long_query_time 就这个值
-- 开启慢查问的性能
set global log_slow_queries=on;
-- 这样就开启了慢查问的性能, 此参数关上了,slow_query_log 就主动变成了 on, 敞开了的话也跟着敞开。
留神:
slow_launch_time
设定跟慢查问日志的查问阀值设定不同,slow_launch_time
示意了 thread create(线程创立)的一个阀值,如果 thread create(线程创立)的工夫超过了这个值,slow_launch_time
的值加 1。set global slow_launch_time=1 这里的工夫值必须是整数,否则的话就话执行出错。long_query_time
示意超过多少秒的查问就写入日志,默认的是 10s, 设置为 0 的话示意记录所有的查问。在 Mysql 5.5 能够追踪到微秒的查问。
开启慢查问:
# 对应的 mysql 配置文件 (my.cnf) 中,并且还得重新启动 mysql 才会失效
slow_query_log=1 # 开启慢查问日志 也能够 slow_query_log =on
slow_query_log_file="D:/phpStudy/1.log" # 慢查问日志文件
log_slow_queries=on # 开启慢查问的性能
long_query_time=2 # 最大等待时间
1.5 查问日志(Query Log)
2. 数据库文件
MySQL 数据库会在 data 目录上面建设一个以数据库为名的文件夹,用来存储数据库中的表文件数据。
不同的数据库引擎,每个表的扩展名也不一样,例如:MyISAM 用“.MYD”作为扩展名,Innodb 用“.ibd”,Archive 用“.arc”,CSV 用“.csv
2.1 .frm 文件
无论是那种存储引擎,创立表之后就肯定会生成一个以表明命名的 .frm
文件。.frm
文件 次要寄存与表相干的数据信息,次要包含表构造的定义信息。当数据库解体时,用户能够通过 frm 文件来复原数据表构造。
2.2 .MYD 文件
.MYD
文件是 MyISAM 存储引擎专用,寄存 MyISAM 表的数据。每一个 MyISAM 表都会有一个 .MYD
文件与之对应,同样寄存于所属数据库的文件夹下,和 .frm
文件在一起。
2.3 .MYI 文件
.MYI
文件也是专属于 MyISAM 存储引擎的,次要寄存 MyISAM 表的索引相干信息。对于 MyISAM 存储来说,能够被 cache 的内容次要就是来源于 .MYI
文件中。每一个 MyISAM 表对应一个 .MYI
文件,寄存于地位和 .frm
以及 .MYD
一样。
2.4 .idb 文件和 iddata 文件
这两种文件都是寄存 Innodb 数据的文件,之所以有两种文件来寄存 Innodb 的数据(包含索引),是因为 Innodb 的数据存储形式可能通过配置来决定是应用共享表空间寄存存储数据,还是独享表空间寄存存储数据。
独享表空间存储形式 应用 .ibd
文件来存放数据,且每个表一个 .ibd
文件,文件寄存在和 MyISAM 数据雷同的地位。如果选用 共享存储表空间 来存放数据,则会应用 ibdata 文件来寄存,所有表独特应用一个(或者多个,可自行配置)ibdata 文件。
ibdata 文件
-
能够通过 innodb_data_home_dir(数据寄存目录)和 innodb_data_file_path(配置每个文件的名称)两个参数配置组成
// innodb_data_file_path 中能够一次配置多个 ibdata 文件 innodb_data_file_path=ibdata1:2000M;ibdata2:10M:autoextend
共享表空间以及独占表空间都是针对数据的存储形式而言的。
共享表空间: 某一个数据库的所有的表数据,索引文件全副放在一个文件中。
独占表空间: 每一个表都将会生成以独立的文件形式来进行存储,每一个表都有一个
.frm
表形容文件,还有一个.ibd
文件。其中这个文件包含了独自一个表的数据内容以及索引内容。
共享表空间和独占表空间的比照
共享表空间:
- 长处:
能够放表空间分成多个文件寄存到各个磁盘上。数据和文件放在一起方便管理。
- 毛病:
所有的数据和索引寄存到一个文件中,多个表及索引在表空间中混合存储,这样对于一个表做了大量删除操作后表空间中将会有大量的空隙,特地是对于统计分析,日值零碎这类利用最不适宜用共享表空间。
独立表空间:
- 长处:
- 每个表都有自已独立的表空间。
- 每个表的数据和索引都会存在自已的表空间中。
- 能够实现单表在不同的数据库中挪动。
- 空间能够回收:
a) Drop table 操作主动回收表空间,如果对于统计分析或是日值表,删除大量数据后能够通过:altertable TableName engine=innodb; 回缩不必的空间。
b) 对于应用独立表空间的表,不管怎么删除,表空间的碎片不会太重大的影响性能,而且还有机会解决。
- 毛病:
- 单表减少过大,如超过 100 个 G。
相比拟之下,应用独占表空间的效率以及性能会更高一点
共享表空间和独立表空间之间的转换
show variables like "innodb_file_per_table";
-- ON 代表独立表空间治理,OFF 代表共享表空间治理;-- 批改数据库的表空间治理形式
-- 批改 innodb_file_per_table 的参数值即可,然而批改不能影响之前曾经应用过的共享表空间和独立表空间;innodb_file_per_table=1 # 1 为应用独占表空间;0 为应用共享表空间
3. 配置文件
3.1 零碎配置文件(my.ini 或 my.cnf)
系统核心配置文件
linux/mac : etc/my.cnf
windows : mysql/my.ini
MySQL 的零碎配置文件个别都是 my.cnf,默认寄存在 ”/etc” 目录下,my.cnf 文件中蕴含多种参数选项组(group),每一种参数组都通过中括号给定了固定的组名,如“[mysqld]”组中包含了 mysqld 服务启动时候的初始化参数,“[client]”组中蕴含着客户端工具程序能够读取的参数。
3.2 socket 文件
MySQL 服务器启动后 socket 文件主动生成,该文件次要用来连贯客户端
在有些时候连贯 MySQL 会呈现如下的问题:
这个问题的解决次要是 sock 文件没有找到.
通常的解决办法:能够尝试重启一下 MySQL 的服务器;如果不信就能够去查找 mysql.sock,并在 my.cnf 中指定该文件的地位(挪动也能够)。