Heim  >  Artikel  >  Datenbank  >  Keine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung

Keine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung

藏色散人
藏色散人nach vorne
2022-11-08 16:47:531851Durchsuche

Dieser Artikel bringt Ihnen das Problem der langsamen MySQL-Abfrageoptimierung näher. Ich werde Sie Schritt für Schritt durch die Analyse, Überprüfung und Optimierung führen.

Keine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung

Erinnern Sie sich an eine langsame MySQL-Abfrageoptimierung – das Laden der Ergebnisse in der Live-Demonstration der Produktionsumgebung dauerte plötzlich nicht mehr Alter Entwickler mit langjähriger Erfahrung, dachte er. Verdammt, dein Gesicht ist eine Ohrfeige.

Aber mit langjähriger Erfahrung in der Welt der Kampfkünste geraten Sie nicht in Panik, wenn etwas passiert, und machen Sie einfach zuerst ein Foto.

Empfohlenes Lernen: „MySQL-Video-Tutorial

Der erste Schritt: SQL analysieren

 ***from event i 
 left join project p on i.project_id = p.project_code 
 left join dict d on i.type_id = d.id 
 left join record re on re.incident_id = i.id
 left join type it on it.id = i.type_id 
 where i.version_flag = 0 and i.flow_id in (大量条件)***复制代码

Wenn flow_id in mit einer großen Anzahl von Bedingungen verbunden ist, verlangsamt sich SQL direkt von den vorherigen 80 ms auf 5,8 Sekunden. Darüber hinaus gibt es hier viele verwandte Tabellen.

Der zweite Schritt besteht darin, den Index zu überprüfen und „explain“ auszuführen. Wenn wir den Index überprüfen und feststellen, dass re.incident_id und i.flow_id nicht indiziert sind, sind wir überglücklich. Das Problem wurde gefunden und der Index ist es Wenn wir jedoch SQL ausführen, stellen wir fest, dass sie nicht indiziert sind. So schlau ich auch bin, ich habe die Erklärung direkt geöffnet und festgestellt, dass der Datensatztyp „Alle“ ist, was bedeutet, dass kein Index vorhanden ist.

warum?warum?

Der dritte Schritt besteht darin, zu prüfen, ob der Feldtyp, die Länge und der Zeichentyp der beiden verwandten Felder konsistent sind Nach einer kurzen Phase der Depression habe ich etwas Neues entdeckt: Der Zeichentyp der ID der

Ereignistabelle ist:

Der Zeichentyp der Incident_ID der Datensatztabelle ist:

Keine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung

Verwenden Sie utf8mb4 entschlossen und einheitlich, um die Einheit mit dem Projektteam aufrechtzuerhalten. Erklären Sie noch einmal, es dauert nur 1 Sekunde, manuell.

Der vierte Schritt besteht darin, die Verwendung von Indexoperationen zu erzwingen. Keine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung

MySQL führt standardmäßig eine Volltextsuche durch, wenn die Indexbasis einer Tabelle zu klein ist. aber die Indexfelder sind im Grunde die gleichen. Im Fall von Daten oder Null müssen Sie immer noch den erzwungenen Index in SQL schreiben. Verwenden Sie die erzwungene Indexlösung in SQL und fügen Sie den erzwungenen Index (alarm_id) nach dem linken Join hinzu

Der fünfte Schritt, IN ist normalerweise, dass der Index

nur dann einen vollständigen Tabellenscan durchführt, wenn die Daten hinter dem IN mehr als 30 % in der Datentabelle übereinstimmen, ohne dass der Index verwendet wird Der Index hängt mit der Datenmenge dahinter zusammen. Mit dem Left-Join können große Datenmengen verarbeitet werden.

Das obige ist der detaillierte Inhalt vonKeine Panik, wenn etwas passiert, zeichnen Sie es zuerst auf: MySQL in langsamer Abfrageoptimierung. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
Dieser Artikel ist reproduziert unter:juejin.im. Bei Verstößen wenden Sie sich bitte an admin@php.cn löschen