Cet article vous donnera une compréhension rapide des requêtes lentes dans MySQL

1. Qu'est-ce qu'une requête lente

Qu'est-ce qu'une requête lente MySQL ? En fait, l'instruction SQL de requête prend beaucoup de temps. Combien de temps faut-il pour calculer une requête lente ? Cela varie en fait d'une personne à l'autre. Certaines entreprises ont un seuil de requête lente de 100 ms, et d'autres peuvent avoir un seuil de 500 ms. Autrement dit, si la durée de la requête dépasse ce seuil, elle est considérée comme une requête lente.

Dans des circonstances normales, MySQL n'activera pas automatiquement les requêtes lentes, et s'il est activé, le seuil par défaut est de 10 secondes

# 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. Les méfaits des requêtes lentes

Puisque nous sommes si préoccupés par les requêtes lentes , il doit être là. Certains inconvénients courants sont les suivants :

1. Mauvaise expérience utilisateur.

Nous devons attendre longtemps pour accéder à quelque chose ou sauvegarder quelque chose, alors ne devrions-nous pas abandonner chaque minute ? Attendez, je sais que l'expérience sera mauvaise, mais définir le seuil de requête lente à 100 ms semble trop bas. Il devrait être acceptable que j'accède à quelque chose pendant 1 à 2 secondes. En fait, ce seuil n'est pas trop bas, car c'est le seuil d'un SQL, et vous devrez peut-être vérifier le SQL plusieurs fois pour une interface, et il est très courant même d'ajuster l'interface externe.

2. Cela occupe la mémoire MySQL et affecte les performances

La mémoire MySQL est intrinsèquement limitée (une grande mémoire nécessite de l'argent supplémentaire !). Pourquoi les requêtes SQL sont-elles lentes ? Parfois, c'est parce que vous analysez la table entière et interrogez une grande quantité de données, associée à divers filtres, que cela devient lent. Par conséquent, les requêtes lentes signifient souvent une augmentation de l'utilisation de la mémoire. Lorsque la mémoire est élevée, les requêtes SQL peuvent être. transportés deviennent moins nombreux et les performances se détériorent.

3. Provoque le blocage des opérations DDL

Comme nous le savons tous, le moteur InnoDB ajoute des verrous de ligne par défaut, mais les verrous sont en fait ajoutés à l'index. Si la condition de filtre ne crée pas d'index, il sera rétrogradé. à un verrou de table. La plupart des raisons de la lenteur des requêtes sont dues au manque d'index. Par conséquent, si le temps de requête lent est trop long, le temps de verrouillage de la table sera également très long. Si DDL est exécuté à ce moment-là, cela provoquera un blocage.

3. Scénarios courants de requêtes lentes

Étant donné que les requêtes lentes causent tant de problèmes, dans quels scénarios les requêtes lentes se produisent-elles généralement ?

1. Aucun index ajouté/échec de la bonne utilisation de l'index

Si

aucun index

n'est ajouté, cela entraînera une analyse complète de la table ou l'index n'est pas atteint (ou l'index n'est pas le bon ; index optimal) , ces deux situations entraîneront une augmentation du nombre de lignes analysées, ce qui entraînera des temps de requête plus lents. Ce qui suit est un exemple de mon 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;

Sous la structure de tableau ci-dessus, j'ai généré aléatoirement un lot de données à tester via

ce site Web. On peut voir que sans indexation, il y a essentiellement 50 000 éléments de données. Ensuite. des requêtes lentes commenceront à apparaître (en supposant que le seuil est de 100 ms)

[Fill Database](https://filldb.info/)

Volume de données100050000100000

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视频教程】

Nombre de champs	Type de requête	Temps de requête
*	Table complète (TOUS )	Environ 80ms
*	Table complète (TOUS)	Environ 120ms
*	Table complète (TOUS)	Environ 180ms

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!