1 背景

我们的业务服务随着功能规模扩大，用户量扩增，流量的不断的增长，经常会遇到一个问题，就是数据存储服务响应变慢。
导致数据库服务变慢的诱因很多，而RD重要的工作之一就是找到问题并解决问题。
下面以MySQL为例子，我们从几个角度分析可能产生原因，并讨论解决的方案。

2 定位慢查询的原因并优化

2.1 慢查询的分析

开启SlowLog，默认是关闭的，由参数slow_query_log决定，在MySQL命令终端中输入下面的命令：

# 是否开启，这边为开启，默认情况下是off
set global slow_query_log=on;

# 设置慢查询阈值，单位是 s，默认为10s，这边的意思是查询耗时超过0.5s，便会记录到慢查询日志里面
set global long_query_time=0.5;

# 确定慢查询日志的文件名和路径
mysql> show global variables like 'slow_query_log_file';
+---------------------+-------------------------------------------------------+
| Variable_name       | Value                                                 |
+---------------------+-------------------------------------------------------+
| slow_query_log_file | /usr/local/mysql/data/MacintoshdeMacBook-Pro-slow.log |
+---------------------+-------------------------------------------------------+
1 row in set (0.00 sec)

# 检查慢查询的详细指标，可以看到下面 slow_query_log = ON，long_query_time = 0.5 ，都是因为我们调整过的
mysql> show global variables like '%quer%';
+----------------------------------------+-------------------------------------------------------+
| Variable_name                          | Value                                                 |
+----------------------------------------+-------------------------------------------------------+
| binlog_rows_query_log_events           | OFF                                                   |
| ft_query_expansion_limit               | 20                                                    |
| have_query_cache                       | NO                                                    |
| log_queries_not_using_indexes          | OFF                                                   |
| log_throttle_queries_not_using_indexes |                                                      |
| long_query_time                        | 0.500000                                             |
| query_alloc_block_size                 | 8192                                                  |
| query_prealloc_size                    | 8192                                                  |
| slow_query_log                         | ON                                                   |
| slow_query_log_file                    | /usr/local/mysql/data/MacintoshdeMacBook-Pro-slow.log |
+----------------------------------------+-------------------------------------------------------+
10 rows in set (0.01 sec)

配置好之后，就会按照阈值默认把慢查询日志收集下来，可以到对应的目录下分析具体的慢请求原因。

2.2 使用Explain进行查询语句分析

2.2.1 分析过程举例

很多时候我们在评审RD同学代码和SQL脚本的时候，上下文和使用环境不了解，不能做出很准确的判断。
这时候使用Explain分析SQL的执行计划就显得非常有用，拿到具体环境中Run一下就能看出很多问题。
举个例子：
模拟一个千万级别的雇员表，我们在没有做索引的字段上做一下查询看看，在500W数据中查询一个名叫LsHfFJA的员工，消耗 2.239S ，获取到一条id为4582071的数据。

再看看他的执行计划，扫描了4952492 条数据才找到该行数据：

mysql> explain select * from emp where empname='LsHfFJA';
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | emp   | ALL  | NULL          | NULL | NULL    | NULL | 4952492 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+---------+-------------+
1 row in set

这就是无索引或者索引不合理的结果，这个时候我们就可以根据实际情况进行查询优化了。

2.2.2 Explain需要关注的指标

比较核心要关注的字段一般有 select_type、type、possible_keys、key、rows、Extra等
我们来一个个说明：

• select_type：代表表示查询中每个select子句的类型，是简单查询还是联合查询还是子查询，一目了然。咱们上面的例子是SIMPLE，代表简单查询，其他枚举参考下列表格：