This article will give you a quick understanding of slow queries in MySQL

1. What is slow query

What is MySQL slow query? In fact, the query SQL statement takes a long time.

How long does it take to calculate a slow query? This actually varies from person to person. Some companies have a slow query threshold of 100ms, and some may have a threshold of 500ms. That is, if the query time exceeds this threshold, it is considered a slow query.

Under normal circumstances, MySQL will not automatically enable slow query, and if it is enabled, the default threshold is 10 seconds

# slow_query_log 表示是否开启
mysql> show global variables like '%slow_query_log%';
+---------------------+--------------------------------------+
| Variable_name       | Value                                |
+---------------------+--------------------------------------+
| slow_query_log      | OFF                                  |
| slow_query_log_file | /var/lib/mysql/0bd9099fc77f-slow.log |
+---------------------+--------------------------------------+

# long_query_time 表示慢查询的阈值，默认10秒
show global variables like '%long_query_time%';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+

2. The dangers of slow query

Since we are so concerned about slow query, it must have some disadvantages. The common ones are as follows:

1. Poor user experience.

We have to wait for a long time to access something or save something, so why don’t we give up every minute? Wait, I know the experience will be poor, but setting the slow query threshold to 100ms seems too low. It should be acceptable for me to access something for 1-2 seconds. In fact, this threshold is not too low, because it is the threshold of a SQL, and you may have to check the SQL several times for one interface, and it is very common to even adjust the external interface.

2. Occupying MySQL memory and affecting performance

MySQL memory is inherently limited (large memory costs extra!). Why is SQL query slow? Sometimes it is because you scan the entire table and query a large amount of data, coupled with various filters, it becomes slow. Therefore, slow queries often mean an increase in memory usage. When the memory is high, the SQL queries that can be carried become smaller. Less, and performance deteriorates.

3. Causes DDL operation blocking

As we all know, the InnoDB engine adds row locks by default, but the locks are actually added to the index. If the filter conditions are not Creating an index will downgrade to table lock. Most of the reasons for slow queries are due to the lack of indexes. Therefore, if the slow query time is too long, the table lock time will also be very long. If DDL is executed at this time, it will cause blocking.

3. Common Scenarios of Slow Query

Since slow query causes so many problems, in what scenarios do slow queries generally occur?

1. No index added/failed to make good use of the index

In the case of

not adding an index, it will cause a full table scan; or The index is not reached (or the index is not the optimal index). These two situations will cause the number of scanned rows to increase, thereby slowing down the query time.

The following is an example of my test:

# 这是我的表结构，算是一种比较常规的表
create table t_user_article
(
    id          bigint unsigned auto_increment
        primary key,
    cid         tinyint(2) default 0                 not null comment 'id',
    title       varchar(100)                         not null,
    author      varchar(15)                          not null,
    content     text                                 not null,
    keywords    varchar(255)                         not null,
    description varchar(255)                         not null,
    is_show     tinyint(1) default 1                 not null comment ' 1 0',
    is_delete   tinyint(1) default 0                 not null comment ' 1 0',
    is_top      tinyint(1) default 0                 not null comment ' 1 0',
    is_original tinyint(1) default 1                 not null,
    click       int(10)    default 0                 not null,
    created_at  timestamp  default CURRENT_TIMESTAMP not null,
    updated_at  timestamp  default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP
)
    collate = utf8mb4_unicode_ci;

Under the above table structure, I passed

[Fill Database](https://filldb.info/) this The website randomly generated a batch of data for testing. It can be seen that without indexing, slow queries will begin after 50,000 pieces of data (assuming the threshold is 100ms)

Data volumeNumber of fieldsQuery typeQuery time 1000*Full table (ALL)About 80ms50000*Full table (ALL)About 120ms100000*Full table (ALL)About 180ms

2、单表数据量太大

如果本身单表数据量太大，可能超千万，或者达到亿级别，可能加了索引之后，个别查询还是存在慢查询的情况，这种貌似没啥好办法，要么就看索引设置得到底对不对，要么就只能分表了。

3、Limit 深分页

深分页的意思就是从比较后面的位置开始进行分页，比如每页有10条，然后我要看第十万页的数据，这时候的分页就会比较“深”

还是上面的 t_user_article 表，你可能会遇到这样的一条深分页查询：

-- 个人测试： 106000条数据，耗时约 150ms
select * from t_user_article where click > 0 order by id limit 100000, 10;

在这种情况下，即使你的 click 字段加了索引，查询速度可能还是很慢（测试后和不加差不多），因为二级索引树存的是主键ID，查到数据还需要进行回表才能决定是否丢弃，像上面的查询，回表的次数就达到了100010次，可想而知速度是非常慢的。

结合上面的分析，目前的解决思路都是先查出主键字段（id），避免回表，再根据主键查出所有字段。

第一种，延迟关联，此时SQL变为：

-- 个人测试： 106000条数据，耗时约 90ms
select * from t_user_article t1, (select id from t_user_article where click > 0 order by id limit 100000, 10) t2  WHERE t1.id = t2.id;

第二种，分开查询，分开查询的意思就是分两次查，此时SQL变为：

-- 个人测试： 106000条数据，耗时约 80ms
select id from t_user_article where click > 0 order by id limit 100000, 10;

-- 个人测试： 106000条数据，耗时约 80ms
select * from t_user_article where id in (上述查询得到的ID)

大家可能会很疑惑，为什么要分开查呢，毕竟分开查可能最终耗时比一次查询还要高！这是因为有些公司（比如我司）可能只对单条SQL的查询时长有要求，但对整体的并没有要求，这时候这种办法就能达到一个折中的效果。

另外，大家在网上可能会看到利用子查询解决的办法，比如改成这样：

select * from t_user_article where id in (select id from t_user_article where click > 0 limit 100000, 10)

但这时候执行你会发现抛出一个错误： “This version of MySQL doesn't yet support 'LIMIT & IN/ALL/ANY/SOME subquery’”，翻译过来就是子查询不支持Limit，解决办法也很简单，多嵌套一层即可：

-- 个人测试： 106000条数据，耗时约 200ms
select * from t_user_article where id in (select t.id from (select id from t_user_article where click > 0 order by id limit 100000, 10) as t)

但问题是测试后发现耗时反而变长了，所以并没有列举为一种解决办法。

4、使用FileSort查询

什么是FileSort查询呢？其实就是当你使用 order by 关键字时，如果待排序的内容不能由所使用的索引直接完成，MySQL就有可能会进行FileSort。

当查询的数据较少，没有超过系统变量 sort_buffer_size  设定的大小，则直接在内存进行排序（快排）；如果超过该变量设定的大小，则会利用文件进行排序（归并）。

FileSort出现的场景主要有以下两种：

4.1 排序字段没加索引

# click 字段此时未加索引
explain select id, click from t_user_article where click > 0 order by click limit 10;

# explain 结果：
type：ALL  Extra：Using where; Using filesort

解决办法就是在 click 字段上加索引。

4.2 使用两个字段排序，但是排序规则不同，一个正序，一个倒序

# click 字段此时已加索引
explain select id, click from t_user_article where click > 0 order by click desc, id asc limit 10;

# explain 结果：
type：range  Extra：Using where; Using index; Using filesort

这种场景常出现于排行榜中，因为排行榜经常需要按照 某个指标倒序 + 创建时间正序 排列。这种目前暂时无解，有解决办法的大佬望在评论区留言。

总结

总的来说，看完本文应该对慢查询有所了解了，慢查询优化是一个经久不衰的话题，场景也非常多元化，需要对索引的原理以及索引命中有一定了解，如有错漏，望大佬们在评论区留言。

【相关推荐：mysql视频教程】

The above is the detailed content of This article will give you a quick understanding of slow queries in MySQL. For more information, please follow other related articles on the PHP Chinese website!