Heim  >  Artikel  >  Datenbank  >  Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild)

Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild)

php是最好的语言
php是最好的语言Original
2018-07-26 16:42:592607Durchsuche

Die MySQL-Leistungsoptimierung umfasst Tabellenoptimierung und Spaltentypauswahl. Worin kann die Tabellenoptimierung unterteilt werden? 1. Trennen Sie Felder fester und variabler Länge. 2. Trennen Sie häufig verwendete Felder von ungewöhnlichen Feldern. 3. Fügen Sie redundante Felder zu 1-zu-vielen-Feldern hinzu, die Korrelationsstatistiken erfordern.

1. Tabellenoptimierung und Spaltentypauswahl

Tabellenoptimierung:

1 wird durch lange Trennzeichen getrennt

Wenn ID int 4 Bytes ausmacht, berücksichtigt CHAR (4) 4 Zeichen Länge, was ebenfalls festgelegt ist.

Kernfelder und häufig verwendete Felder sollten auf eine feste Länge aufgebaut und in einer Tabelle platziert werden.

und VARCHAR-, Text-, Blob- und lange Felder eignen sich zum Platzieren einer einzelnen Tabelle und werden über den Hauptschlüssel mit der Kerntabelle verknüpft.

2. Die häufig verwendeten Felder und die ungewöhnlichen Felder sollten getrennt werden.

Sie müssen das spezifische Geschäft der Website analysieren, die Abfrageszene des Felds analysieren und abfragen Feld mit niedriger Frequenz, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single , Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single Single, Single allein Nimm es auseinander.

3. Fügen Sie in einem Paar redundante Felder zu den Feldern hinzu, die mit Statistiken verknüpft werden müssen.

Sehen Sie sich die folgenden Effekte an:

In jedem Abschnitt gibt es n Beiträge. Auf der Startseite werden die Abschnittsinformationen und Beiträge unter dem angezeigt Abschnittsnummer.

Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild)                                                                                                                                                                                                      *) aus der Beitragsgruppe nach Board_ID, um die Anzahl der Beiträge in jedem Board zu erhalten.

2. Auswahl des Spaltentyps

Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild) 1. Feldtyppriorität

Ganzzahltyp>Datum

time>enum

char>varchar>blob,text

Ganzzahltyp: feste Länge, keine Land-/Regionsunterscheidung, kein Zeichensatzunterschied. Zum Beispiel:

tinyint 1,2,3,4,5 char(1) a,b,c,d,e

In Bezug auf den Platz alle belegen 1 Byte, aber die Sortierung erfolgt schneller. Der Grund kann darin liegen, dass der Zeichensatz und der Sortiersatz (dh die Sortierregeln) berücksichtigt werden müssen.

Die Zeit hat eine feste Länge, ist schnell und spart Platz. In Anbetracht der Zeitzone ist es unpraktisch, SQL zu schreiben, in dem „2018-08-08“;

enum, das als Einschränkung dienen kann, intern unter Verwendung von Ganzzahlen gespeichert wird, bei gemeinsamer Abfrage jedoch mit cahr , die interne Konvertierung von Zeichenfolgen und Werten;

char hat eine feste Länge, unter Berücksichtigung des Zeichensatzes und des (Sortier-)Korrekturlesesatzes;

varchar hat eine variable Länge und die Konvertierung des Zeichensatzes und des Korrekturlesesatzes müssen beim Sortieren berücksichtigt werden

Text/Blob kann keine temporären Speichertabellen verwenden (Sortierung und andere Vorgänge können nur auf der Festplatte durchgeführt werden)

Anhang: In Bezug auf die Auswahl von Datum und Uhrzeit ist die klare Meinung des Meisters klar: Wählen Sie direkt int unsgined und nicht null und speichern Sie den Zeitstempel.

Zum Beispiel:

Geschlecht: Nehmen Sie utf8 als Beispiel

char(1), 3 Bytes lang

enum('Male',' Female '); Intern in Zahlen zur Speicherung konvertiert, ein weiterer Konvertierungsvorgang

tinyint(), feste Länge 1 Byte

2. Verwenden Sie einfach genug, seien Sie nicht großzügig (z as smallint varchar(N))

Grund: Große Bytes verschwenden Speicher und beeinträchtigen die Geschwindigkeit.

Am Beispiel des Alters kann tinyint unsigned not null das Alter von 255 Jahren speichern, was ausreichend ist. Die Verwendung von int verschwendet 3 Bytes;

Der in varchar(10) und varchar(300) gespeicherte Inhalt ist derselbe, aber varchar(300) verbraucht während der Tabellenverknüpfungsabfrage mehr Speicher.

3. Vermeiden Sie die Verwendung von NULL()

Grund: NULL ist für die Indizierung nicht förderlich und muss mit Sonderzeichen gekennzeichnet werden.

nimmt tatsächlich mehr Speicherplatz auf der Festplatte ein (MySQL5.5 hat null verbessert, aber die Abfrage ist immer noch unpraktisch)

3. Strategie zur Indexoptimierung

1. Indextyp

                                                                             

Es wird Btree-Index genannt. Im Großen und Ganzen verwenden sie alle ausgewogene Bäume, aber in Bezug auf die spezifische Implementierung ist jede Engine etwas anders. Genau genommen verwendet die NDB-Engine beispielsweise T-Tree.

Aber wenn man das B-Tree-System abstrahiert, kann es als „sortierte schnelle Abfragestruktur“ verstanden werden.

1.2 Hash-Index

Der Standardwert ist der Hash-Index in der Speichertabelle, und die theoretische Abfragezeitkomplexität des Hash beträgt O(1).

Frage: Da die Hash-Suche so effizient ist, warum nicht den Hash-Index verwenden?

Antwort:

1. Das von der Hash-Funktion berechnete Ergebnis ist zufällig. Wenn die Daten auf der Festplatte abgelegt werden, nehmen wir als Beispiel den Primärschlüssel, dann wächst die ID , die id Die entsprechenden Zeilen werden zufällig auf der Festplatte platziert.

2. Bereichsabfragen können nicht optimiert werden.

3. Der Präfixindex kann beispielsweise nicht in btree verwendet werden, der Wert der Feldspalte ist „helloworld“, und die Indexabfrage x=helloworld kann natürlich den Index verwenden, und x=hello kann Verwenden Sie auch den Index (linker Präfixindex).

4. Die Sortierung kann nicht optimiert werden.

5. Die Zeile muss zurückgegeben werden, dh der Datenspeicherort muss über den Index ermittelt werden und die Daten müssen an die Tabelle zurückgegeben werden.

2. Häufige Missverständnisse über Btree-Indizes

2.1 Fügen Sie Indizes zu Spalten hinzu, die häufig in Where-Bedingungen verwendet werden, zum Beispiel:

wobei cat_id = 3 und Preis>100; Überprüfen Sie die dritte Spalte auf Produkte über 100 Yuan.

Missverständnis: Fügen Sie Indizes sowohl zur cat_id als auch zum Preis hinzu.

Fehler: Nur cat_id oder Preisindex können verwendet werden, da es sich um unabhängige Indizes handelt und nur einer gleichzeitig verwendet werden kann.

2.2 Nach dem Erstellen eines Index für mehrere Spalten (gemeinsamer Index) funktioniert der Index unabhängig von der abgefragten Spalte

Missverständnis: Damit der Index auf einem mehrspaltigen Index funktioniert, muss der Die Anforderung für das linke Präfix muss erfüllt sein.

Nehmen Sie index(a,b,c) als Beispiel (beachten Sie, dass es von der Reihenfolge abhängt)

Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild)

4

Zum Beispiel: Wählen Sie * aus t4 aus, wobei c1=3 und c2 = 4 und c4>5 und c3=2;

Welche Indizes verwendet werden:

Erkläre „select *“ aus t4, wobei c1=3 und c2 = 4 und c4>5 und c3=2 G

wie folgt:

Tutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild)

                                                                                                                

5. Clustered-Index und Nicht-Clustered-Index

Myisam und Innodb-Engine, Ähnlichkeiten und Unterschiede in Indexdateien

Myisam: bestehend aus news.myd und new. myi Die beiden Dateien, die Indexdatei und die Datendatei, sind getrennt und werden als nicht gruppierte Indizes bezeichnet. Sowohl der Primärindex als auch der Sekundärindex verweisen auf die physische Zeile (Speicherort auf der Festplatte)

innodb: Der Index und die Daten sind in einem Cluster zusammengefasst, es handelt sich also um einen Clustered-Index. Die Datenzeile wird direkt in der Primärindexdatei von innodb gespeichert, und der Sekundärindex verweist auf einen Verweis auf den Primärschlüsselindex.

Hinweis: Für innodb:

1. Der Primärschlüsselindex speichert den Indexwert und die Zeilendaten in den Blättern.

2. Wenn kein Primärschlüssel vorhanden ist, wird der eindeutige Schlüssel als Primärschlüssel verwendet.

3. Wenn kein eindeutiger Schlüssel vorhanden ist, generiert das System eine interne Zeilen-ID als Primärschlüssel.

4. In der Primärschlüsselindexstruktur werden sowohl der Primärschlüsselwert als auch die Zeilendaten gespeichert. Diese Struktur wird als Clustered-Index bezeichnet.

Clustered Index

Vorteil: Wenn relativ wenige Abfrageeinträge basierend auf dem Primärschlüssel vorhanden sind, ist kein Zurückgehen erforderlich (die Daten befinden sich unter dem Primärschlüssel). Knoten)

Nachteil: Wenn unregelmäßige Daten eingefügt werden, kommt es häufig zu Seitenaufteilungen

Verwandte Artikel:

MySQL-Leistungsoptimierung

Verwandte Videos:

Video-Tutorial zur MySQL-Optimierung

Das obige ist der detaillierte Inhalt vonTutorial zur Leistungsoptimierung von MySQL-Big-Data-Abfragen (Bild). Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!

Stellungnahme:
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