Dieser Artikel vermittelt Ihnen einen schnellen Überblick über langsame Abfragen in MySQL

1. Was ist eine langsame Abfrage?

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. Der Schaden langsamer Abfragen. Da wir uns große Sorgen um langsame Abfragen machen , es muss da sein. Zu den häufigsten Nachteilen gehören:

1. Schlechte Benutzererfahrung.

Wir müssen lange warten, um auf etwas zuzugreifen oder etwas zu speichern. Warum also nicht jede Minute aufgeben? Warten Sie, ich weiß, dass die Erfahrung schlecht sein wird, aber die Einstellung des Schwellenwerts für langsame Abfragen auf 100 ms scheint zu niedrig zu sein. Es sollte für mich akzeptabel sein, 1–2 Sekunden lang auf etwas zuzugreifen. Tatsächlich ist dieser Schwellenwert nicht zu niedrig, da es sich um den Schwellenwert einer SQL handelt und Sie die SQL möglicherweise mehrmals für eine Schnittstelle überprüfen müssen, und es kommt sehr häufig vor, dass sogar die externe Schnittstelle angepasst wird.

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?

1. Kein Index hinzugefügt/der Index konnte nicht ordnungsgemäß genutzt werden

Wenn

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;

Unter der obigen Tabellenstruktur habe ich zufällig einen Datenstapel zum Testen über diese Website generiert. Es ist ersichtlich, dass es im Grunde genommen 50.000 Daten gibt Es werden langsame Abfragen angezeigt (vorausgesetzt, der Schwellenwert liegt bei 100 ms). )

Ungefähr 80 ms

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

50000**Vollständige Tabelle (ALLE)

Vollständige Tabelle (ALLE)	Ungefähr 120 ms		100000
Etwa 180 ms		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视频教程】

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!