在mysql如何查找效率慢的SQL语句

32次阅读

共计 12704 个字符，预计需要花费 32 分钟才能阅读完成。

这篇文章主要介绍在 mysql 如何查找效率慢的 SQL 语句，文中介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们一定要看完！

一、MySQL 数据库有几个配置选项可以帮助我们及时捕获低效 SQL 语句
1，slow_query_log
这个参数设置为 ON，可以捕获执行时间超过一定数值的 SQL 语句。
2，long_query_time
当 SQL 语句执行时间超过此数值时，就会被记录到日志中，建议设置为 1 或者更短。
3，slow_query_log_file
记录日志的文件名。
4，log_queries_not_using_indexes
这个参数设置为 ON，可以捕获到所有未使用索引的 SQL 语句，尽管这个 SQL 语句有可能执行得挺快。
二、检测 mysql 中 sql 语句的效率的方法
1、通过查询日志
（1）、Windows 下开启 MySQL 慢查询
MySQL 在 Windows 系统中的配置文件一般是是 my.ini 找到[mysqld] 下面加上
代码如下
log-slow-queries = F:/MySQL/log/mysqlslowquery。log
long_query_time = 2

（2）、Linux 下启用 MySQL 慢查询
MySQL 在 Windows 系统中的配置文件一般是是 my.cnf 找到[mysqld] 下面加上
代码如下
log-slow-queries=/data/mysqldata/slowquery。log
long_query_time=2
说明
log-slow-queries = F:/MySQL/log/mysqlslowquery。
为慢查询日志存放的位置，一般这个目录要有 MySQL 的运行帐号的可写权限，一般都将这个目录设置为 MySQL 的数据存放目录；
long_query_time= 2 中的 2 表示查询超过两秒才记录；

2.show processlist 命令
WSHOW PROCESSLIST 显示哪些线程正在运行。您也可以使用 mysqladmin processlist 语句得到此信息。
各列的含义和用途：
ID 列
一个标识，你要 kill 一个语句的时候很有用，用命令杀掉此查询 /*/mysqladmin kill 进程号。
user 列
显示单前用户，如果不是 root，这个命令就只显示你权限范围内的 sql 语句。
host 列
显示这个语句是从哪个 ip 的哪个端口上发出的。用于追踪出问题语句的用户。
db 列
显示这个进程目前连接的是哪个数据库。
command 列
显示当前连接的执行的命令，一般就是休眠（sleep），查询（query），连接（connect）。
time 列
此这个状态持续的时间，单位是秒。
state 列
显示使用当前连接的 sql 语句的状态，很重要的列，后续会有所有的状态的描述，请注意，state 只是语句执行中的某一个状态，一个 sql 语句，以查询为例，可能需要经过 copying to tmp table，Sorting result，Sending data 等状态才可以完成
info 列
显示这个 sql 语句，因为长度有限，所以长的 sql 语句就显示不全，但是一个判断问题语句的重要依据。
这个命令中最关键的就是 state 列，mysql 列出的状态主要有以下几种：
Checking table
正在检查数据表（这是自动的）。
Closing tables
正在将表中修改的数据刷新到磁盘中，同时正在关闭已经用完的表。这是一个很快的操作，如果不是这样的话，就应该确认磁盘空间是否已经满了或者磁盘是否正处于重负中。
Connect Out
复制从服务器正在连接主服务器。
Copying to tmp table on disk
由于临时结果集大于 tmp_table_size，正在将临时表从内存存储转为磁盘存储以此节省内存。
Creating tmp table
正在创建临时表以存放部分查询结果。
deleting from main table
服务器正在执行多表删除中的第一部分，刚删除第一个表。
deleting from reference tables
服务器正在执行多表删除中的第二部分，正在删除其他表的记录。
Flushing tables
正在执行 FLUSH TABLES，等待其他线程关闭数据表。
Killed
发送了一个 kill 请求给某线程，那么这个线程将会检查 kill 标志位，同时会放弃下一个 kill 请求。MySQL 会在每次的主循环中检查 kill 标志位，不过有些情况下该线程可能会过一小段才能死掉。如果该线程程被其他线程锁住了，那么 kill 请求会在锁释放时马上生效。
Locked
被其他查询锁住了。
Sending data
正在处理 SELECT 查询的记录，同时正在把结果发送给客户端。
Sorting for group
正在为 GROUP BY 做排序。
Sorting for order
正在为 ORDER BY 做排序。
Opening tables
这个过程应该会很快，除非受到其他因素的干扰。例如，在执 ALTER TABLE 或 LOCK TABLE 语句行完以前，数据表无法被其他线程打开。正尝试打开一个表。
Removing duplicates
正在执行一个 SELECT DISTINCT 方式的查询，但是 MySQL 无法在前一个阶段优化掉那些重复的记录。因此，MySQL 需要再次去掉重复的记录，然后再把结果发送给客户端。
Reopen table
获得了对一个表的锁，但是必须在表结构修改之后才能获得这个锁。已经释放锁，关闭数据表，正尝试重新打开数据表。
Repair by sorting
修复指令正在排序以创建索引。
Repair with keycache
修复指令正在利用索引缓存一个一个地创建新索引。它会比 Repair by sorting 慢些。
Searching rows for update
正在讲符合条件的记录找出来以备更新。它必须在 UPDATE 要修改相关的记录之前就完成了。
Sleeping
正在等待客户端发送新请求.
System lock
正在等待取得一个外部的系统锁。如果当前没有运行多个 mysqld 服务器同时请求同一个表，那么可以通过增加 –skip-external-locking 参数来禁止外部系统锁。
Upgrading lock
INSERT DELAYED 正在尝试取得一个锁表以插入新记录。
Updating
正在搜索匹配的记录，并且修改它们。
User Lock
正在等待 GET_LOCK()。
Waiting for tables
该线程得到通知，数据表结构已经被修改了，需要重新打开数据表以取得新的结构。然后，为了能的重新打开数据表，必须等到所有其他线程关闭这个表。以下几种情况下会产生这个通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 或 OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED 已经处理完了所有待处理的插入操作，正在等待新的请求。
大部分状态对应很快的操作，只要有一个线程保持同一个状态好几秒钟，那么可能是有问题发生了，需要检查一下。
还有其他的状态没在上面中列出来，不过它们大部分只是在查看服务器是否有存在错误是才用得着。
例如如图：

3、explain 来了解 SQL 执行的状态
explain 显示了 mysql 如何使用索引来处理 select 语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。
使用方法，在 select 语句前加上 explain 就可以了：
例如：

1
explain select surname,first_name form a,b where a.id=b.id
结果如图

EXPLAIN 列的解释
table
显示这一行的数据是关于哪张表的
type
这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为 const、eq_reg、ref、range、indexhe 和 ALL
possible_keys
显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从 WHERE 语句中选择一个合适的语句
key
实际使用的索引。如果为 NULL，则没有使用索引。很少的情况下，MYSQL 会选择优化不足的索引。这种情况下，可以在 SELECT 语句中使用 USE INDEX（indexname）来强制使用一个索引或者用 IGNORE INDEX（indexname）来强制 MYSQL 忽略索引
key_len
使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref
显示索引的哪一列被使用了，如果可能的话，是一个常数
rows
MYSQL 认为必须检查的用来返回请求数据的行数
Extra
关于 MYSQL 如何解析查询的额外信息。将在表 4.3 中讨论，但这里可以看到的坏的例子是 Using temporary 和 Using filesort，意思 MYSQL 根本不能使用索引，结果是检索会很慢
extra 列返回的描述的意义
Distinct
一旦 MYSQL 找到了与行相联合匹配的行，就不再搜索了
Not exists
MYSQL 优化了 LEFT JOIN，一旦它找到了匹配 LEFT JOIN 标准的行，就不再搜索了
Range checked for each Record（index map:#）
没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL 检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
Using filesort
看到这个的时候，查询就需要优化了。MYSQL 需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
Using index
列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
Using temporary
看到这个的时候，查询需要优化了。这里，MYSQL 需要创建一个临时表来存储结果，这通常发生在对不同的列集进行 ORDER BY 上，而不是 GROUP BY 上
Where used
使用了 WHERE 从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型 ALL 或 index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）
const
表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为 MYSQL 先读这个值然后把它当做常数来对待
eq_ref
在连接中，MYSQL 在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
ref
这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
range
这个连接类型使用索引返回一个范围中的行，比如使用或查找东西时发生的情况
index
这个连接类型对前面的表中的每一个记录联合进行完全扫描（比 ALL 更好，因为索引一般小于表数据）
ALL
这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免

MySQL – 查看慢 SQL
查看 MySQL 是否启用了查看慢 SQL 的日志文件
（1）查看慢 SQL 日志是否启用
mysql show variables like log_slow_queries

+——————+——-+
| Variable_name | Value |
+——————+——-+
| log_slow_queries | ON |
+——————+——-+
1 row in set (0.00 sec)
（2）查看执行慢于多少秒的 SQL 会记录到日志文件中
mysql show variables like long_query_time
+—————–+——-+
| Variable_name | Value |
+—————–+——-+
| long_query_time | 1 |

+—————–+——-+
1 row in set (0.00 sec)
这里 value=1，表示 1 秒
2. 配置 my.ini 文件（inux 下文件名为 my.cnf），查找到[mysqld] 区段，增加日志的配置，如下示例：
[mysqld]
log= C:/temp/mysql.log
log_slow_queries= C:/temp/mysql_slow.log
long_query_time=1
log 指示日志文件存放目录；
log_slow_queries 指示记录执行时间长的 sql 日志目录；
long_query_time 指示多长时间算是执行时间长，单位 s。
Linux 下这些配置项应该已经存在，只是被注释掉了，可以去掉注释。但直接添加配置项也 OK 啦。
查询到效率低的 SQL 语句后，可以通过 EXPLAIN 或者 DESC 命令获取 MySQL 如何执行 SELECT 语句的信息，包括在 SELECT 语句执行过程中表如何连接和连接的顺序，比如我们想计算 2006 年所有公司的销售额，需要关联 sales 表和 company 表，并且对 profit 字段做求和（sum）操作，相应 SQL 的执行计划如下：

mysql explain select sum(profit) from sales a,company b where a.company_id = b.id and a.year = 2006\G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: a

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 12

Extra: Using where

*************************** 2. row ***************************

id: 1

select_type: SIMPLE

table: b

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 12

Extra: Using where

2 rows in set (0.00 sec)
每个列的解释如下：
•select_type：表示 SELECT 的类型，常见的取值有 SIMPLE（简单表，即不使用表连接或者子查询）、PRIMARY（主查询，即外层的查询）、UNION（UNION 中的第二个或者后面的查询语句）、SUBQUERY（子查询中的第一个 SELECT）等。
•table：输出结果集的表。
•type：表示表的连接类型，性能由好到差的连接类型为 system（表中仅有一行，即常量表）、const（单表中最多有一个匹配行，例如 primary key 或者 unique index）、eq_ref（对于前面的每一行，在此表中只查询一条记录，简单来说，就是多表连接中使用 primary key 或者 unique index）、ref（与 eq_ref 类似，区别在于不是使用 primary key 或者 unique index，而是使用普通的索引）、ref_or_null（与 ref 类似，区别在于条件中包含对 NULL 的查询）、index_merge (索引合并优化)、unique_subquery（in 的后面是一个查询主键字段的子查询）、index_subquery（与 unique_subquery 类似，区别在于 in 的后面是查询非唯一索引字段的子查询）、range（单表中的范围查询）、index（对于前面的每一行，都通过查询索引来得到数据）、all（对于前面的每一行，都通过全表扫描来得到数据）。
•possible_keys：表示查询时，可能使用的索引。

•key：表示实际使用的索引。

•key_len：索引字段的长度。

•rows：扫描行的数量。

•Extra：执行情况的说明和描述。
在上面的例子中，已经可以确认是对 a 表的全表扫描导致效率的不理想，那么对 a 表的 year 字段创建索引，具体如下：
mysql create index idx_sales_year on sales(year);

Query OK, 12 rows affected (0.01 sec)

Records: 12 Duplicates: 0 Warnings: 0
创建索引后，这条语句的执行计划如下：

mysql explain select sum(profit) from sales a,company b where a.company_id = b.id and a.year = 2006\G;

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: a

type: ref

possible_keys: idx_sales_year

key: idx_sales_year

key_len: 4

ref: const

rows: 3

Extra:

*************************** 2. row ***************************

id: 1

select_type: SIMPLE

table: b

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 12

Extra: Using where

2 rows in set (0.00 sec)
可以发现建立索引后对 a 表需要扫描的行数明显减少（从全表扫描减少到 3 行），可见索引的使用可以大大提高数据库的访问速度，尤其在表很庞大的时候这种优势更为明显，使用索引优化 sql 是优化问题 sql 的一种常用基本方法，在后面的章节中我们会具体介绍如何使索引来优化 sql。
本文主要介绍的是 MySQL 慢查询分析方法，前一段日子，我曾经设置了一次记录在 MySQL 数据库中对慢于 1 秒钟的 SQL 语句进行查询。想起来有几个十分设置的方法，有几个参数的名称死活回忆不起来了，于是重新整理一下，自己做个笔记。
对于排查问题找出性能瓶颈来说，最容易发现并解决的问题就是 MySQL 慢查询以及没有得用索引的查询。
OK，开始找出 MySQL 中执行起来不“爽”的 SQL 语句吧。
MySQL 慢查询分析方法一：
这个方法我正在用，呵呵，比较喜欢这种即时性的。
MySQL5.0 以上的版本可以支持将执行比较慢的 SQL 语句记录下来。
MySQL show variables like long%
注：这个 long_query_time 是用来定义慢于多少秒的才算“慢查询”
+—————–+———–+
| Variable_name | Value |
+—————–+———–+
| long_query_time | 10.000000 |
+—————–+———–+
1 row in set (0.00 sec)
MySQL set long_query_time=1;
注：我设置了 1, 也就是执行时间超过 1 秒的都算慢查询。
Query OK, 0 rows affected (0.00 sec)
MySQL show variables like slow%
+———————+—————+
| Variable_name | Value |
+———————+—————+
| slow_launch_time | 2 |
| slow_query_log | ON |
注：是否打开日志记录
| slow_query_log_file | /tmp/slow.log |
注：设置到什么位置
+———————+—————+
3 rows in set (0.00 sec)
MySQL set global slow_query_log= ON
注：打开日志记录
一旦 slow_query_log 变量被设置为 ON，MySQL 会立即开始记录。
/etc/my.cnf 里面可以设置上面 MySQL 全局变量的初始值。
long_query_time=1 slow_query_log_file=/tmp/slow.log
MySQL 慢查询分析方法二:
MySQLdumpslow 命令
/path/MySQLdumpslow -s c -t 10 /tmp/slow-log
这会输出记录次数最多的 10 条 SQL 语句，其中：
-s, 是表示按照何种方式排序，c、t、l、r 分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙;
-t, 是 top n 的意思，即为返回前面多少条的数据;
-g, 后边可以写一个正则匹配模式，大小写不敏感的;
比如
/path/MySQLdumpslow -s r -t 10 /tmp/slow-log
得到返回记录集最多的 10 个查询。
/path/MySQLdumpslow -s t -t 10 -g“left join”/tmp/slow-log
得到按照时间排序的前 10 条里面含有左连接的查询语句。

简单点的方法：
打开 my.ini , 找到 [mysqld] 在其下面添加 long_query_time = 2 log-slow-queries = D:/mysql/logs/slow.log #设置把日志写在那里，可以为空，系统会给一个缺省的文件 #log-slow-queries = /var/youpath/slow.log linux 下 host_name-slow.log log-queries-not-using-indexes long_query_time 是指执行超过多长时间（单位是秒）的 sql 会被记录下来，这里设置的是 2 秒。
以下是 mysqldumpslow 常用参数说明，详细的可应用 mysqldumpslow -help 查询。 -s，是表示按照何种方式排序，c、t、l、r 分别是按照记录次数、时间、查询时间、返回的记录数来排序（从大到小），ac、at、al、ar 表示相应的倒叙。 -t，是 top n 的意思，即为返回前面多少条数据。www.jb51.net -g，后边可以写一个正则匹配模式，大小写不敏感。接下来就是用 mysql 自带的慢查询工具 mysqldumpslow 分析了（mysql 的 bin 目录下），我这里的日志文件名字是 host-slow.log。列出记录次数最多的 10 个 sql 语句 mysqldumpslow -s c -t 10 host-slow.log 列出返回记录集最多的 10 个 sql 语句 mysqldumpslow -s r -t 10 host-slow.log 按照时间返回前 10 条里面含有左连接的 sql 语句 mysqldumpslow -s t -t 10 -g left join host-slow.log 使用 mysqldumpslow 命令可以非常明确的得到各种我们需要的查询语句，对 MySQL 查询语句的监控、分析、优化起到非常大的帮助

在日常开发当中，经常会遇到页面打开速度极慢的情况，通过排除，确定了，是数据库的影响，为了迅速查找具体的 SQL，可以通过 Mysql 的日志记录方法。
— 打开 sql 执行记录功能
set global log_output= TABLE — 输出到表
set global log=ON; — 打开所有命令执行记录功能 general_log, 所有语句: 成功和未成功的.
set global log_slow_queries=ON; — 打开慢查询 sql 记录 slow_log, 执行成功的: 慢查询语句和未使用索引的语句
set global long_query_time=0.1; — 慢查询时间限制(秒)
set global log_queries_not_using_indexes=ON; — 记录未使用索引的 sql 语句
— 查询 sql 执行记录
select * from mysql.slow_log order by 1; — 执行成功的：慢查询语句, 和未使用索引的语句
select * from mysql.general_log order by 1; — 所有语句：成功和未成功的.
— 关闭 sql 执行记录
set global log=OFF;
set global log_slow_queries=OFF;
— long_query_time 参数说明
— v4.0, 4.1, 5.0, v5.1 到 5.1.20(包括): 不支持毫秒级别的慢查询分析(支持精度为 1 -10 秒);
— 5.1.21 及以后版本 : 支持毫秒级别的慢查询分析, 如 0.1;
— 6.0 到 6.0.3: 不支持毫秒级别的慢查询分析(支持精度为 1 -10 秒);
— 6.0.4 及以后: 支持毫秒级别的慢查询分析;
通过日志中记录的 Sql，迅速定位到具体的文件，优化 sql 看一下，是否速度提升了呢？

本文针对 MySQL 数据库服务器查询逐渐变慢的问题，进行分析，并提出相应的解决办法，具体的分析解决办法如下：会经常发现开发人员查一下没用索引的语句或者没有 limit n 的语句，这些没语句会对数据库造成很大的影 …

本文针对 MySQL 数据库服务器查询逐渐变慢的问题，进行分析，并提出相应的解决办法，具体的分析解决办法如下：
会经常发现开发人员查一下没用索引的语句或者没有 limit n 的语句，这些没语句会对数据库造成很大的影响，例如一个几千万条记录的大表要全部扫描，或者是不停的做 filesort，对数据库和服务器造成 io 影响等。这是镜像库上面的情况。
而到了线上库，除了出现没有索引的语句，没有用 limit 的语句，还多了一个情况,mysql 连接数过多的问题。说到这里，先来看看以前我们的监控做法

1. 部署 zabbix 等开源分布式监控系统，获取每天的数据库的 io，cpu，连接数

2. 部署每周性能统计，包含数据增加量，iostat，vmstat，datasize 的情况

3. Mysql slowlog 收集，列出 top 10
以前以为做了这些监控已经是很完美了，现在部署了 mysql 节点进程监控之后，才发现很多弊端

第一种做法的弊端: zabbix 太庞大，而且不是在 mysql 内部做的监控，很多数据不是非常准备，现在一般都是用来查阅历史的数据情况

第二种做法的弊端：因为是每周只跑一次，很多情况没法发现和报警

第三种做法的弊端: 当节点的 slowlog 非常多的时候，top10 就变得没意义了，而且很多时候会给出那些是一定要跑的定期任务语句给你。。参考的价值不大

那么我们怎么来解决和查询这些问题呢
对于排查问题找出性能瓶颈来说，最容易发现并解决的问题就是 MYSQL 的慢查询以及没有得用索引的查询。

OK，开始找出 mysql 中执行起来不“爽”的 SQL 语句吧。
方法一：这个方法我正在用，呵呵，比较喜欢这种即时性的。
Mysql5.0 以上的版本可以支持将执行比较慢的 SQL 语句记录下来。
mysql show variables like long% 注：这个 long_query_time 是用来定义慢于多少秒的才算“慢查询”
+—————–+———–+
| Variable_name | Value |
+—————–+———–+
| long_query_time | 10.000000 |
+—————–+———–+
1 row in set (0.00 sec)
mysql set long_query_time=1; 注：我设置了 1, 也就是执行时间超过 1 秒的都算慢查询。
Query OK, 0 rows affected (0.00 sec)
mysql show variables like slow%
+———————+—————+
| Variable_name | Value |
+———————+—————+
| slow_launch_time | 2 |
| slow_query_log | ON | 注：是否打开日志记录
| slow_query_log_file | /tmp/slow.log | 注：设置到什么位置
+———————+—————+
3 rows in set (0.00 sec)
mysql set global slow_query_log= ON 注：打开日志记录
一旦 slow_query_log 变量被设置为 ON，mysql 会立即开始记录。
/etc/my.cnf 里面可以设置上面 MYSQL 全局变量的初始值。
long_query_time=1
slow_query_log_file=/tmp/slow.log
方法二:mysqldumpslow 命令
/path/mysqldumpslow -s c -t 10 /tmp/slow-log
这会输出记录次数最多的 10 条 SQL 语句，其中：
-s, 是表示按照何种方式排序，c、t、l、r 分别是按照记录次数、时间、查询时间、返回的记录数来排序，ac、at、al、ar，表示相应的倒叙；
-t, 是 top n 的意思，即为返回前面多少条的数据；
-g, 后边可以写一个正则匹配模式，大小写不敏感的；
比如
/path/mysqldumpslow -s r -t 10 /tmp/slow-log
得到返回记录集最多的 10 个查询。
/path/mysqldumpslow -s t -t 10 -g“left join”/tmp/slow-log
得到按照时间排序的前 10 条里面含有左连接的查询语句。
最后总结一下节点监控的好处

1．轻量级的监控，而且是实时的，还可以根据实际的情况来定制和修改

2．设置了过滤程序，可以对那些一定要跑的语句进行过滤

3．及时发现那些没有用索引，或者是不合法的查询，虽然这很耗时去处理那些慢语句，但这样可以避免数据库挂掉，还是值得的

4. 在数据库出现连接数过多的时候，程序会自动保存当前数据库的 processlist，DBA 进行原因查找的时候这可是利器
5. 使用 mysqlbinlog 来分析的时候，可以得到明确的数据库状态异常的时间段

有些人会建义我们来做 mysql 配置文件设置
调节 tmp_table_size 的时候发现另外一些参数

Qcache_queries_in_cache 在缓存中已注册的查询数目

Qcache_inserts 被加入到缓存中的查询数目

Qcache_hits 缓存采样数数目

Qcache_lowmem_prunes 因为缺少内存而被从缓存中删除的查询数目

Qcache_not_cached 没有被缓存的查询数目 (不能被缓存的，或由于 QUERY_CACHE_TYPE)

Qcache_free_memory 查询缓存的空闲内存总数

Qcache_free_blocks 查询缓存中的空闲内存块的数目

Qcache_total_blocks 查询缓存中的块的总数目

Qcache_free_memory 可以缓存一些常用的查询, 如果是常用的 sql 会被装载到内存。那样会增加数据库访问速度