この記事では、MySQL の遅いクエリについて簡単に理解できます。

#1. スロー クエリとは何ですか。

MySQL のスロー クエリとは何ですか?実際、クエリ SQL ステートメントには長い時間がかかります。

遅いクエリの計算にはどのくらい時間がかかりますか?これは実際には人によって異なります。遅いクエリのしきい値を 100 ミリ秒としている企業もあれば、500 ミリ秒のしきい値を設定している企業もあります。つまり、クエリ時間がこのしきい値を超えると、遅いクエリとみなされます。

通常の状況では、MySQL はスロー クエリを自動的に有効にしません。有効になっている場合、デフォルトのしきい値は 10 秒です

# 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. スロー クエリの危険性

クエリが遅いことを非常に懸念しているため、いくつかの欠点があるはずです。一般的な欠点は次のとおりです:

1. ユーザー エクスペリエンスが低い。

何かにアクセスしたり、何かを保存したりするのに長い時間待たなければならないのに、毎分諦めてはどうでしょうか?エクスペリエンスが低下することはわかっていますが、低速クエリのしきい値を 100 ミリ秒に設定するのは低すぎるように思えます。1 ～ 2 秒間何かにアクセスするのは許容できるはずです。実際、このしきい値は SQL のしきい値であるため、低すぎるわけではありません。1 つのインターフェイスに対して SQL を数回チェックする必要がある場合があり、外部インターフェイスを調整することも非常に一般的です。

2. MySQL メモリの占有とパフォーマンスへの影響

MySQL メモリは本質的に制限されています (メモリが大きいと追加コストがかかります!) SQL クエリが遅いのはなぜですか?場合によっては、テーブル全体をスキャンし、さまざまなフィルターと組み合わせて大量のデータをクエリすると、処理が遅くなることがあります。したがって、クエリが遅いということは、メモリ使用量の増加を意味することがよくあります。メモリが多い場合、SQL クエリは、搭載できる量が少なくなり、性能が低下します。

3. DDL 操作のブロックを引き起こす

ご存知のとおり、InnoDB エンジンはデフォルトで行ロックを追加しますが、ロックは実際にはインデックスに追加されます。フィルター条件が満たされていないインデックスを作成すると、テーブル ロックにダウングレードされます。クエリが遅い原因のほとんどはインデックスの不足によるもので、クエリ時間が長すぎるとテーブルのロック時間も非常に長くなり、このときに DDL が実行されるとブロッキングが発生します。

3. 遅いクエリの一般的なシナリオ

遅いクエリは非常に多くの問題を引き起こすため、一般的にどのようなシナリオで遅いクエリが発生するのでしょうか?

1. インデックスが追加されていない/インデックスを有効に活用できていない

インデックスを追加していないの場合、次のような問題が発生します。テーブル全体のスキャン、または

インデックスに到達しない (またはインデックスが最適なインデックスではない)

これら 2 つの状況により、スキャンされる行数が増加し、クエリ時間が遅くなります。 以下は私のテストの例です:

# 这是我的表结构，算是一种比较常规的表
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;

上記のテーブル構造の下で、

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

を渡しました。この Web サイトは、テスト用にデータのバッチをランダムに生成しました。インデックスを作成しないと、データが 50,000 個になると遅いクエリが開始されることがわかります (しきい値が 100 ミリ秒であると仮定します)

データ量フィールド数 1000**

クエリタイプ	クエリ時間
#テーブル全体 (すべて)	約 80ms		50000
フルテーブル (すべて)	約 120 ミリ秒		100000
テーブル全体 (すべて)	概要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视频教程】

以上がこの記事では、MySQL の遅いクエリについて簡単に理解できます。の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。