Artikel ini akan memberi anda pemahaman pantas tentang pertanyaan lambat dalam MySQL

1. Apakah pertanyaan lambat? Sebenarnya, pernyataan SQL pertanyaan mengambil masa lama

.

Berapa lama masa yang diambil untuk mengira pertanyaan yang perlahan? Ini sebenarnya berbeza dari orang ke orang Sesetengah syarikat mempunyai ambang pertanyaan yang perlahan sebanyak 100ms, dan sesetengahnya mungkin mempunyai ambang 500ms. Iaitu, jika masa pertanyaan melebihi ambang ini, ia dianggap sebagai pertanyaan yang perlahan.

Dalam keadaan biasa, MySQL tidak akan mendayakan pertanyaan perlahan secara automatik, dan jika ia didayakan, ambang lalai ialah 10 saat

2 Bahaya pertanyaan lambat# 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 | +-----------------+-----------+

Kita perlu menunggu lama untuk mengakses sesuatu atau menyimpan sesuatu, jadi tidakkah kita harus berputus asa setiap minit? Tunggu, saya tahu pengalaman itu akan menjadi buruk, tetapi menetapkan ambang pertanyaan perlahan kepada 100ms nampaknya terlalu rendah untuk saya mengakses sesuatu selama 1-2 saat. Malah, ambang ini tidak terlalu rendah, kerana ia adalah ambang SQL, dan anda mungkin perlu menyemak SQL beberapa kali untuk satu antara muka, dan adalah sangat biasa untuk melaraskan antara muka luaran.

2. Menduduki memori MySQL dan menjejaskan prestasi

Memori MySQL sememangnya terhad (memori yang besar memerlukan kos tambahan! Mengapa pertanyaan SQL lambat? Kadang-kadang kerana anda mengimbas keseluruhan jadual dan menanyakan sejumlah besar data, ditambah dengan pelbagai penapis, ia menjadi perlahan Oleh itu, pertanyaan perlahan sering bermakna peningkatan dalam penggunaan memori Apabila memori tinggi, pertanyaan SQL yang boleh dibawa menjadi lebih kecil, dan prestasi merosot.

3. Menyebabkan operasi DDL tersekat

Seperti yang kita sedia maklum, enjin InnoDB menambah kunci baris secara lalai, tetapi kunci itu sebenarnya ditambahkan pada indeks keadaan penapis tidak Mencipta indeks akan menurunkan taraf kepada kunci jadual. Kebanyakan sebab pertanyaan lambat adalah kerana kekurangan indeks Oleh itu, jika masa pertanyaan lambat terlalu lama, masa kunci jadual juga akan menjadi sangat lama Jika DDL dilaksanakan pada masa ini, ia akan menyebabkan penyekatan.

3. Senario Biasa Pertanyaan Lambat

Memandangkan pertanyaan lambat menyebabkan banyak masalah, dalam senario apakah pertanyaan lambat biasanya berlaku?

1. Tiada pengindeksan/kegagalan untuk menggunakan indeks dengan baik

Dalam kes tiada pengindeksan

, imbasan jadual penuh akan berlaku; atau

Indeks tidak dicapai (atau indeks bukan indeks yang optimum)

Kedua-dua situasi ini akan membawa kepada peningkatan dalam bilangan baris yang diimbas, sekali gus memperlahankan masa pertanyaan.

Berikut ialah contoh ujian saya:

Di bawah struktur jadual di atas, saya menjana sekumpulan data secara rawak untuk ujian melalui laman web ini dalam Tanpa pengindeksan, pertanyaan perlahan akan bermula selepas 50,000 keping data (dengan mengandaikan ambangnya ialah 100ms)

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

Atas ialah kandungan terperinci Artikel ini akan memberi anda pemahaman pantas tentang pertanyaan lambat dalam MySQL. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!