什麼是MySQL慢查詢呢？其實就是查詢的SQL語句耗費較長的時間。
具體耗費多久算慢查詢呢？這其實因人而異，有些公司慢查詢的閾值是100ms，有些的閾值可能是500ms，即查詢的時間超過這個閾值即視為慢查詢。
正常情況下，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 | +-----------------+-----------+
既然我們這麼關注慢查詢，那它肯定是有一些不好的地方，常見的有這幾個：
1、用戶體驗差。
我們去參觀一個東西，或是保存一個東西，都得等好久，那不分分鐘棄坑？等等，我知道體驗是會差，但慢查詢的閾值設定為100ms似不似太低了，我訪問一個東西1-2秒應該也能接受吧。其實這個閾值不算太低，因為這是一條SQL的閾值，而你一個介面可能要查好幾次SQL，甚至連上外部介面都是很常見的。
2、佔用MySQL內存，影響效能
MySQL記憶體本來就是有限的（大記憶體要加錢！），SQL為什麼查詢慢呢？有時候就是因為你全表掃導致查詢的資料量很多，再加上各種篩選就變慢了，所以慢查詢往往也會意味著記憶體佔用的增高，記憶體一高，能夠承載的SQL查詢就變少了，性能也變差了。
3、造成DDL操作阻塞
眾所周知，InnoDB引擎預設加的是行鎖，但鎖其實都是加在索引上的，如果篩選條件沒有建立索引，會降級到表鎖。而慢查詢有一大部分原因都是因為沒加索引導致的，所以慢查詢時間過長，就會導致表鎖的時間也很長，如果這時候執行DDL就會造成阻塞。
既然慢查詢造成的問題這麼多，那一般什麼場景下會出現慢查詢呢？
1、沒加索引/沒利用好索引
在沒加索引的情況，就會造成全表掃描；又或者沒走到索引（或走的不是最優索引），這兩張情況都會導致掃描行數增多，從而查詢時間變慢。
下面是我測試的一個範例：
# 这是我的表结构，算是一种比较常规的表
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/) 這個網站隨機產生了一批資料進行測驗，可以看到，在沒加索引的前提下，基本5萬個資料後就會開始出現慢查詢了（假設閾值為100ms）
| 資料量 | 欄位數量 | 查詢類型 | 查詢時間 |
|---|---|---|---|
| 1000 | * | 全表（ALL） | 約80ms |
| 50000 | * | 全表（ALL） | 約120ms |
| #100000 | * | 全表（ALL） | 約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中文網其他相關文章！
