Was ist eine langsame MySQL-Abfrage? Tatsächlich dauert die SQL-Abfrageanweisung sehr lange. Wie lange dauert die Berechnung einer langsamen Abfrage? Dies ist tatsächlich von Person zu Person unterschiedlich. Einige Unternehmen haben einen Schwellenwert für langsame Abfragen von 100 ms, andere können einen Schwellenwert von 500 ms haben. Das heißt, wenn die Abfragezeit diesen Schwellenwert überschreitet, wird dies als langsame Abfrage angesehen.
Unter normalen Umständen aktiviert MySQL langsame Abfragen nicht automatisch. Wenn sie aktiviert ist, beträgt der Standardschwellenwert 10 Sekunden.
# 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. Es belegt MySQL-Speicher und beeinträchtigt die Leistung
MySQL-Speicher ist von Natur aus begrenzt (großer Speicher kostet extra!), warum ist SQL-Abfrage langsam? Manchmal ist die von Ihnen abgefragte Datenmenge groß, weil Sie die gesamte Tabelle scannen. In Verbindung mit verschiedenen Filtern wird sie daher langsam. Daher bedeuten langsame Abfragen oft eine Erhöhung der Speicherauslastung wird kleiner und die Leistung nimmt ab.3. Verursacht eine Blockierung des DDL-Vorgangs
Wie wir alle wissen, fügt die InnoDB-Engine standardmäßig Zeilensperren hinzu, aber die Sperren werden tatsächlich zum Index hinzugefügt zu einem Tischschloss. Die meisten Gründe für langsame Abfragen sind auf das Fehlen von Indizes zurückzuführen. Wenn also die langsame Abfragezeit zu lang ist, ist auch die Tabellensperrzeit sehr lang. Wenn DDL zu diesem Zeitpunkt ausgeführt wird, führt dies zu einer Blockierung.3. Häufige Szenarien langsamer Abfragen
Da langsame Abfragen so viele Probleme verursachen, in welchen Szenarien treten langsame Abfragen im Allgemeinen auf?kein Index hinzugefügt wird, führt dies zu einem vollständigen Tabellenscan; oder der Index wird nicht erreicht optimaler Index)
, Beide Situationen führen zu einer Erhöhung der Anzahl der gescannten Zeilen, was zu langsameren Abfragezeiten führt.Das Folgende ist ein Beispiel für meinen 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;Ungefähr 80 ms
[Fill Database](https://filldb.info/)
| Vollständige Tabelle (ALLE) | Ungefähr 120 ms | 100000 | |
|---|---|---|---|
| Etwa 180 ms | 2、单表数据量太大 如果本身单表数据量太大，可能超千万，或者达到亿级别，可能加了索引之后，个别查询还是存在慢查询的情况，这种貌似没啥好办法，要么就看索引设置得到底对不对，要么就只能分表了。 3、Limit 深分页 深分页的意思就是从比较后面的位置开始进行分页，比如每页有10条，然后我要看第十万页的数据，这时候的分页就会比较“深” 还是上面的 -- 个人测试： 106000条数据，耗时约 150ms select * from t_user_article where click > 0 order by id limit 100000, 10; Nach dem Login kopieren 在这种情况下，即使你的 结合上面的分析，目前的解决思路都是先查出主键字段（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; Nach dem Login kopieren 第二种，分开查询，分开查询的意思就是分两次查，此时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) Nach dem Login kopieren 大家可能会很疑惑，为什么要分开查呢，毕竟分开查可能最终耗时比一次查询还要高！这是因为有些公司（比如我司）可能只对单条SQL的查询时长有要求，但对整体的并没有要求，这时候这种办法就能达到一个折中的效果。 另外，大家在网上可能会看到利用子查询解决的办法，比如改成这样： select * from t_user_article where id in (select id from t_user_article where click > 0 limit 100000, 10) Nach dem Login kopieren 但这时候执行你会发现抛出一个错误： “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) Nach dem Login kopieren 但问题是测试后发现耗时反而变长了，所以并没有列举为一种解决办法。 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 Nach dem Login kopieren 解决办法就是在 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 Nach dem Login kopieren 这种场景常出现于排行榜中，因为排行榜经常需要按照 某个指标倒序 + 创建时间正序 排列。这种目前暂时无解，有解决办法的大佬望在评论区留言。 总结总的来说，看完本文应该对慢查询有所了解了，慢查询优化是一个经久不衰的话题，场景也非常多元化，需要对索引的原理以及索引命中有一定了解，如有错漏，望大佬们在评论区留言。 【相关推荐：mysql视频教程】 Das obige ist der detaillierte Inhalt vonDieser Artikel vermittelt Ihnen einen schnellen Überblick über langsame Abfragen in MySQL. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
Verwandte Etiketten：
Quelle：juejin.cn
Vorheriger Artikel：Kennen Sie die Auswirkungen des MySQL-innodb-Selbstinkrementierungs-ID-Fehlers?
Nächster Artikel：Dieser Artikel hilft Ihnen, den MySQL-Ausführungsplan schnell zu verstehen
Erklärung dieser Website
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn
Neueste Artikel des Autors
Aktuelle Ausgaben
Wie gruppiere und zähle ich in MySQL?
Ich versuche, eine Abfrage zu schreiben, die die Gesamtzahl der nicht gelöschten Nachricht...
Aus 2024-04-06 18:30:17
0
1
353
verwandte Themen
Mehr>
Beliebte Empfehlungen
Beliebte Tutorials
Mehr>
Neueste Downloads
Mehr>
|
