MySQL慢查询优化

前言：在应用开发的早期，数据量少，程序猿开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时候这些有问题的慢查询SQL语句就是整个系统性能的瓶颈。

一、 SQL慢查询简介

1.1、什么是SQL慢查询？

这里指的是MySQL慢查询，具体指运行时间超过long_query_time值的SQL。

我们常听常见的MySQL中有二进制日志binlog、中继日志relaylog、重做回滚日志redolog、undolog等。针对慢查询，还有一种慢查询日志slowlog，用来记录在MySQL中响应时间超过阀值的语句。

大家不要被慢查询这个名字误导，以为慢查询日志只会记录select语句，其实也会记录执行时间超过了long_query_time设定的阈值的insert、update等DML语句。

# 查看慢SQL是否开启

show variables like "slow_query_log%";

# 查看慢查询设定的阈值 单位:秒

show variables like "long_query_time";

MySQL默认10s内没有响应SQL结果，则为慢查询，当然我们也可以修改这个默认时间。

1.2、开启慢查询

MySQL 支持通过以下方式开启慢查询：

• 输入命令开启慢查询（临时），在 MySQL 服务重启后会自动关闭；

• 配置 my.cnf（Windows 是 my.ini）系统文件开启，修改配置文件是持久化开启慢查询的方式。

①命令行方式

#开启慢查询命令

set global slow_query_log='ON';

#指定记录慢查询日志 SQL 执行时间得阈值（long_query_time 单位：秒，默认 10 秒）

如下我设置成了 1 秒，执行时间超过 1 秒的 SQL 将记录到慢查询日志中：

set global long_query_time=1;

#查询 “慢查询日志文件存放位置”。

show variables like '%slow_query_log_file%';

slow_query_log_file 指定慢查询日志的存储路径及文件（默认和数据文件放一起）

mysql> show variables like '%slow_query_log_file%';
 
+---------------------+-----------------------------------+
 
| Variable_name       | Value                             |
 
+---------------------+-----------------------------------+
 
| slow_query_log_file | /var/lib/mysql/localhost-slow.log |
 
+---------------------+-----------------------------------+
 
1 row in set (0.01 sec)

#核对慢查询开启状态，需要退出当前 MySQL 终端，重新登录即可刷新。

配置了慢查询后，它会记录以下符合条件的 SQL：

• 查询语句

• 数据修改语句

• 已经回滚的 SQL

②配置 my.cnf文件方式

通过配置 my.cnf（Windows 是 my.ini）系统文件开启（版本：MySQL 5.5 及以上）。

编辑/etc/my.cnf下的MySQL的配置文件，在 my.cnf 文件的 [mysqld] 下增加如下配置开启慢查询，如下图：

# 开启慢查询功能
 
slow_query_log=ON
 
# 指定记录慢查询日志SQL执行时间得阈值
 
long_query_time=1
 
# 选填，默认数据文件路径
 
# slow_query_log_file=/var/lib/mysql/localhost-slow.log

设置完成之后，重启MySQL

service mysql restart

1.3、SQL慢查询为何会导致系统故障？

真实的慢SQL往往会伴随着大量的行扫描、临时文件排序或者频繁的磁盘flush，直接影响就是磁盘IO升高，正常SQL也变为了慢SQL，大面积执行超时。

一条慢查询会造成什么后果？之前我一直觉得不就是返回数据会慢一些么，用户体验变差？其实远远不止，我经历过几次线上事故，有一次就是由一条 SQL 慢查询导致的。

那次是一条 SQL 查询耗时达到 2-3 秒，没有命中索引，导致全表扫描，由于是高频查询，并发一起来很快就把 DB 线程池打满了，导致大量查询请求堆积，DB 服务器 CPU 长时间 100%+，大量请求 timeout.....最终系统崩溃，老板登场！可见，团队如果对慢查询不引起足够的重视，风险是很大的。

---

二、慢SQL优化一般步骤

1、通过慢查日志等定位那些执行效率较低的SQL语句

2、explain 分析SQL的执行计划

需要重点关注type、rows、filtered、extra。

type由上至下，效率越来越高

• ALL 全表扫描

• index 索引全扫描

• range 索引范围扫描，一般条件查询中出现了>、<、in、between等查询

• ref 使用非唯一索引扫描或唯一索引前缀扫描，返回单条记录，常出现在关联查询中

• eq_ref 类似ref，区别在于使用的是唯一索引，使用主键的关联查询

• const/system 单条记录，系统会把匹配行中的其他列作为常数处理，如主键或唯一索引查询

• null MySQL不访问任何表或索引，直接返回结果 虽然上至下，效率越来越高，但是根据cost模型，假设有两个索引idx1(a, b, c),idx2(a, c)，SQL为"select * from t where a = 1 and b in (1, 2) order by c";如果走idx1，那么是type为range，如果走idx2，那么type是ref；当需要扫描的行数，使用idx2大约是idx1的5倍以上时，会用idx1，否则会用idx2

Extra

• Using filesort：MySQL需要额外的一次传递，以找出如何按排序顺序检索行。通过根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关键字和行的指针来完成排序。然后关键字被排序，并按排序顺序检索行。

• Using temporary：使用了临时表保存中间结果，性能特别差，需要重点优化

• Using index：表示相应的 select 操作中使用了覆盖索引（Coveing Index）,避免访问了表的数据行，效率不错！如果同时出现 using where，意味着无法直接通过索引查找来查询到符合条件的数据。

• Using index condition：MySQL5.6之后新增的ICP，using index condtion就是使用了ICP（索引下推），在存储引擎层进行数据过滤，而不是在服务层过滤，利用索引现有的数据减少回表的数据。

3、show profile 分析

了解SQL执行的线程的状态及消耗的时间。默认是关闭的，开启语句“set profiling = 1;”

SHOW PROFILES ;
 
SHOW PROFILE FOR QUERY  #{id};
 
//可以看到profiling 默认是OFF的
show variables like "%pro%";

4、trace

trace分析优化器如何选择执行计划，通过trace文件能够进一步了解为什么优惠券选择A执行计划而不选择B执行计划。

set optimizer_trace="enabled=on";
 
set optimizer_trace_max_mem_size=1000000;
 
select * from information_schema.optimizer_trace;

5、确定问题并采用相应的措施

优化索引

优化SQL语句：修改SQL、IN 查询分段、时间查询分段、基于上一次数据过滤

改用其他实现方式：ES、数仓等

数据碎片处理

---

三、Explain 分析慢查询 SQL

3.1、explain 分析SQL的执行计划

explain能解释mysql如何处理SQL语句，表的加载顺序，表是如何连接，以及索引使用情况。是SQL优化的重要工具。

分析 MySQL 慢查询日志，利用 Explain 关键字可以模拟优化器执行 SQL 查询语句，来分析 SQL 慢查询语句。

下面我们的测试表是一张 137w 数据的 app 信息表，我们来举例分析一下。

SQL 示例如下：

-- 1.185s
 
SELECT * from vio_basic_domain_info where app_name like '%翻译%' ;

这是一条普通的模糊查询语句，查询耗时：1.185s，查到了 148 条数据。

我们用 Explain 分析结果如下表，根据表信息可知：该 SQL 没有用到字段 app_name 上的索引，查询类型是全表扫描，扫描行数 137w。

mysql> EXPLAIN SELECT * from vio_basic_domain_info where app_name like '%翻译%' ;
 
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
 
| id | select_type | table                 | partitions | type | possible_keys | key  | key_len | ref  | rows    | filtered | Extra       |
 
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
 
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | ALL  | NULL          | NULL | NULL    | NULL | 1377809 |    11.11 | Using where |
 
+----+-------------+-----------------------+------------+------+---------------+------+---------+------+---------+----------+-------------+
 
1 row in set, 1 warning (0.00 sec)

当这条 SQL 使用到索引时，SQL 如下：查询耗时：0.156s，查到 141 条数据：

-- 0.156s
 
SELECT * from vio_basic_domain_info where app_name like '翻译%' ;

Explain 分析结果如下表；根据表信息可知：该 SQL 用到了 idx_app_name 索引，查询类型是索引范围查询，扫描行数 141 行。由于查询的列不全在索引中（select *），因此回表了一次，取了其他列的数据。

mysql> EXPLAIN SELECT * from vio_basic_domain_info where app_name like '翻译%' ;
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
 
| id | select_type | table                 | partitions | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra                 |
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
 
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | range | idx_app_name  | idx_app_name | 515     | NULL |  141 |   100.00 | Using index condition |
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+-----------------------+
 
1 row in set, 1 warning (0.00 sec)

当这条 SQL 使用到覆盖索引时，SQL 如下：查询耗时：0.091s，查到 141 条数据。

-- 0.091s
 
SELECT app_name from vio_basic_domain_info where app_name like '翻译%' ;

Explain 分析结果如下表；根据表信息可知：和上面的 SQL 一样使用到了索引，由于查询列就包含在索引列中，又省去了 0.06s 的回表时间。

mysql> EXPLAIN SELECT app_name from vio_basic_domain_info where app_name like '翻译%' ;
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
 
| id | select_type | table                 | partitions | type  | possible_keys | key          | key_len | ref  | rows | filtered | Extra                    |
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
 
|  1 | SIMPLE      | vio_basic_domain_info | NULL       | range | idx_app_name  | idx_app_name | 515     | NULL |  141 |   100.00 | Using where; Using index |
 
+----+-------------+-----------------------+------------+-------+---------------+--------------+---------+------+------+----------+--------------------------+
 
1 row in set, 1 warning (0.00 sec)

那么是如何通过 EXPLAIN 解析结果分析 SQL 的呢？各列属性又代表着什么？一起往下看。

3.2、面试官问：说说你对mysql中explain各个字段的见解吧？

首先我们需要理解各个字段的含义，才能更好用好explain这个关键字

(1) 各列属性的简介如下

• id：SELECT 的查询序列号，体现执行优先级，如果是子查询，id的序号会递增，id 值越大优先级越高，越先被执行；

• select_type：表示查询的类型；

• table：输出结果集的表，如设置了别名，也会显示；

• partitions：匹配的分区；

• type：对表的访问方式；

• possible_keys：表示查询时，可能使用的索引；

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

• key_len：索引字段的长度；

• ref：列与索引的比较；

• rows：扫描出的行数（估算的行数）；

• filtered：按表条件过滤的行百分比；

• Extra：执行情况的描述和说明。这一列显示一些额外信息，很重要。

(2 )慢查询分析常用到的属性

1）type

对表访问方式，表示 MySQL 在表中找到所需行的方式，又称“访问类型”。

存在的类型有：ALL、index、range、ref、eq_ref、const、system、NULL（从左到右，性能从低到高）。

介绍三个咱们天天见到的：

• ALL：（Full Table Scan）MySQL 将遍历全表以找到匹配的行，常说的全表扫描；

• Index：（Full Index Scan）Index 与 ALL 区别为 Index 类型只遍历索引树；

• Range：只检索给定范围的行，使用一个索引来选择行。

system：表只有一行记录，这个是const的特例，一般不会出现，可以忽略

const：表示通过索引一次就找到了，const用于比较primary key或者unique索引。因为只匹配一行数据，所以很快。

eq_ref：唯一性索引扫描，表中只有一条记录与之匹配。一般是两表关联，关联条件中的字段是主键或唯一索引。

ref：非唯一行索引扫描，返回匹配某个单独值的所有行

range：检索给定范围的行，一般条件查询中出现了>、<、in、between等查询

index：遍历索引树。通常比ALL快，因为索引文件通常比数据文件小。all和index都是读全表，但index是从索引中检索的，而all是从硬盘中检索的。

all：遍历全表以找到匹配的行

2）key

key 列显示了 SQL 实际使用索引，通常是 possible_keys 列中的索引之一，MySQL 优化器一般会通过计算扫描行数来选择更适合的索引，如果没有选择索引，则返回 NULL。

当然，MySQL 优化器存在选择索引错误的情况，可以通过修改 SQL 强制MySQL“使用或忽视某个索引”：

• 强制使用一个索引：FORCE INDEX (index_name)、USE INDEX (index_name)；

• 强制忽略一个索引：IGNORE INDEX (index_name)。

3）rows

rows 是 MySQL 估计为了找到所需的行而要读取（扫描）的行数，可能不精确。

4）Extra

这一列显示一些额外信息，很重要。

Using index：查询的列被索引覆盖，并且 where 筛选条件是索引的是前导列，Extra 中为 Using index。意味着通过索引查找就能直接找到符合条件的数据，无须回表。

注：前导列一般指联合索引中的第一列或“前几列”，以及单列索引的情况；这里为了方便理解我统称为前导列。

Using where：说明 MySQL 服务器将在存储引擎检索行后再进行过滤；即没有用到索引，回表查询。

可能的原因：

• 查询的列未被索引覆盖；

• where 筛选条件非索引的前导列或无法正确使用到索引。

Using temporary：这意味着 MySQL 在对查询结果排序时会使用一个临时表。

Using filesort：说明 MySQL 会对结果使用一个外部索引排序，而不是按索引次序从表里读取行。

Using index condition：查询的列不全在索引中，where 条件中是一个前导列的范围。5.6之后新增的，表示查询的列有非索引的列，先判断索引的条件，以减少磁盘的IO

Using where；Using index：查询的列被索引覆盖，并且 where 筛选条件是索引列之一，但不是索引的前导列或出现了其他影响直接使用索引的情况（如存在范围筛选条件等），Extra 中为 Using where；Using index，意味着无法直接通过索引查找来查询到符合条件的数据，影响并不大。

---

四、慢查询SQL优化场景

 强烈推荐大家看这篇博客： MySQL学习笔记-怎么写出更好的SQL

4.1、最左匹配

索引

KEY `idx_shopid_orderno` (`shop_id`,`order_no`)

SQL语句

select * from _t where orderno=''

查询匹配从左往右匹配，要使用order_no走索引，必须查询条件携带shop_id或者索引(shop_id,order_no)调换前后顺序。

4.2、隐式转换

索引

KEY `idx_mobile` (`mobile`)

SQL语句

select * from _user where mobile=12345678901

隐式转换相当于在索引上做运算，会让索引失效。mobile是字符类型，使用了数字，应该使用字符串匹配，否则MySQL会用到隐式替换，导致索引失效。

4.3、大分页

索引

KEY `idx_a_b_c` (`a`, `b`, `c`)

SQL语句

select * from _t where a = 1 and b = 2 order by c desc limit 10000, 10;

对于大分页的场景，可以优先让产品优化需求，如果没有优化的，有如下两种优化方式， 一种是把上一次的最后一条数据，也即上面的c传过来，然后做“c < xxx”处理，但是这种一般需要改接口协议，并不一定可行。

另一种是采用延迟关联的方式进行处理，减少SQL回表，但是要记得索引需要完全覆盖才有效果，SQL改动如下

select t1.* from _t t1, (select id from _t where a = 1 and b = 2 order by c desc limit 10000, 10) t2 where t1.id = t2.id;

4.4、in + order by

索引

KEY `idx_shopid_status_created` (`shop_id`, `order_status`, `created_at`)

SQL语句

select * from _order where shop_id = 1 and order_status in (1, 2, 3) order by created_at desc limit 10

in查询在MySQL底层是通过n*m的方式去搜索，类似union，但是效率比union高。in查询在进行cost代价计算时（代价 = 元组数 * IO平均值），是通过将in包含的数值，一条条去查询获取元组数的，因此这个计算过程会比较的慢，所以MySQL设置了个临界值(eq_range_index_dive_limit)，5.6之后超过这个临界值后该列的cost就不参与计算了。

因此会导致执行计划选择不准确。默认是200，即in条件超过了200个数据，会导致in的代价计算存在问题，可能会导致Mysql选择的索引不准确。

处理方式，可以(order_status, created_at)互换前后顺序，并且调整SQL为延迟关联。

4.5、范围查询阻断，后续字段不能走索引

索引

KEY `idx_shopid_created_status` (`shop_id`, `created_at`, `order_status`)

SQL语句

select * from _order where shop_id = 1 and created_at > '2021-01-01 00:00:00' and order_status = 10

范围查询还有“IN、between”

4.6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）

select * from _order where shop_id=1 and order_status not in (1,2)
select * from _order where shop_id=1 and order_status != 1

在索引上，避免使用NOT、!=、<>、!<、!>、NOT EXISTS、NOT IN、NOT LIKE等

4.7、优化器选择不使用索引的情况

如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。

select * from _order where  order_status = 1

查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。

4.8、复杂查询

select sum(amt) from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01';
select * from _t where a = 1 and b in (1, 2, 3) and c > '2020-01-01' limit 10;

如果是统计某些数据，可能改用数仓进行解决；

如果是业务上就有那么复杂的查询，可能就不建议继续走SQL了，而是采用其他的方式进行解决，比如使用ES等进行解决。

4.9、asc和desc混用

select * from _t where a=1 order by b desc, c asc

desc 和asc混用时会导致索引失效

4.10、大数据

对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在MySQL上，并且做7天等有效期的保存。

那么需要注意，频繁的清理数据，会照成数据碎片，需要联系DBA进行数据碎片处理。

---

参考链接：

原来count(*)就是我们系统的接口性能变差100倍的真凶…

查询太慢？SQL 优化这么做就对了！

老板：谁再搞出这类SQL慢查询事故，直接走人！