遅いクエリの計算にはどのくらい時間がかかりますか?これは実際には人によって異なります。遅いクエリのしきい値を 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;
上記のテーブル構造の下で、
を渡しました。この Web サイトは、テスト用にデータのバッチをランダムに生成しました。インデックスを作成しないと、データが 50,000 個になると遅いクエリが開始されることがわかります (しきい値が 100 ミリ秒であると仮定します)
クエリタイプ | クエリ時間 | ||
---|---|---|---|
#テーブル全体 (すべて) | 約 80ms | 50000 | |
フルテーブル (すべて) | 約 120 ミリ秒 | 100000 | |
テーブル全体 (すべて) | 概要180ms |
2、单表数据量太大 如果本身单表数据量太大,可能超千万,或者达到亿级别,可能加了索引之后,个别查询还是存在慢查询的情况,这种貌似没啥好办法,要么就看索引设置得到底对不对,要么就只能分表了。 3、Limit 深分页 深分页的意思就是从比较后面的位置开始进行分页,比如每页有10条,然后我要看第十万页的数据,这时候的分页就会比较“深” 还是上面的 -- 个人测试: 106000条数据,耗时约 150ms select * from t_user_article where click > 0 order by id limit 100000, 10; 在这种情况下,即使你的 结合上面的分析,目前的解决思路都是先查出主键字段(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出现的场景主要有以下两种: 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 サイトの他の関連記事を参照してください。