Heim  >  Artikel  >  Datenbank  >  Details zur Berechnung der Indexlänge in MySQL

Details zur Berechnung der Indexlänge in MySQL

黄舟
黄舟Original
2017-03-01 13:31:022267Durchsuche

Schauen wir uns zunächst eine Frage an. Für Tabelle t enthält sie drei Felder a, b, c. Unter der Annahme, dass ihre Standardwerte nicht leer sind, erstellen wir nun einen kombinierten Indexindex (a, b, c) Analyse Was ist der Unterschied zwischen „select * from t“ mit a=1 und c=1 und „select * from t“ mit a=1 und b=1?

Erstellen Sie zuerst die Tabelle


Führen Sie diese beiden Elemente aus bzw. Die Aussage


stellt fest, dass der Unterschied zwischen den beiden Aussagen hauptsächlich in key_len liegt. Warum sind die Unterschiede? zwischen den beiden Aussagen unterschiedlich?

Mein Verständnis ist:

Wir können uns den kombinierten Index als das Verzeichnis der ersten Ebene, das Verzeichnis der zweiten Ebene usw. vorstellen Das Verzeichnis der dritten Ebene des Buches, z. B. index(a,b,c), entspricht a einem Verzeichnis der ersten Ebene, b einem Verzeichnis der zweiten Ebene unter dem Verzeichnis der ersten Ebene und c einem Verzeichnis der dritten Ebene Verzeichnis unter dem Verzeichnis der zweiten Ebene. Um ein Verzeichnis zu verwenden, müssen Sie zunächst das übergeordnete Verzeichnis verwenden, mit Ausnahme des Verzeichnisses der ersten Ebene.

Also

wobei a=1 und c=1 nur das Verzeichnis der ersten Ebene verwenden, c befindet sich im dritten Verzeichnis. Wenn das Verzeichnis der zweiten Ebene nicht verwendet wird und kein Verzeichnis der zweiten Ebene verwendet wird, kann das Verzeichnis der dritten Ebene nicht verwendet werden wobei a=1 und b=1 nur ein Verzeichnis der ersten Ebene und ein Verzeichnis der zweiten Ebene verwenden.

Die key_len der zweiten Abfrage ist also größer.

Aber wie wird key_len berechnet? Wie berechnen wir oben 4 und 8? Ich habe dem vorher nicht viel Aufmerksamkeit geschenkt.
Bei der Analyse der Leistung von SQL-Abfrageanweisungen mithilfe von EXPLAIN habe ich diesmal mehr auf „select_type“, „type“, „möglicher_schlüssel“, „key“, „ref“ und „rows“ geachtet Klären Sie die Berechnung von key_len.

1 Wenn nicht null festgelegt ist, muss ein Byte hinzugefügt werden.

2. Feld mit fester Länge, int belegt vier Bytes, date belegt drei Bytes und char(n) belegt n Zeichen.

3. Für das Feld varchar(n) gibt es n Zeichen + zwei Bytes.

4. Bei verschiedenen Zeichensätzen ist die Anzahl der von einem Zeichen belegten Bytes unterschiedlich. Bei der Latin1-Codierung belegt ein Zeichen ein Byte, bei der GBK-Codierung belegt ein Zeichen zwei Bytes und bei der UTF8-Codierung belegt ein Zeichen drei Bytes.

Daher kann geschlossen werden, dass

wobei a=1 und c = Wobei a=1 und c=1, key_len=4+4=8


Jetzt stellen wir uns eine weitere Frage: Erstellen Sie eine t2-Tabelle mit der folgenden Datenstruktur:

Execute EXPLAIN Select * from t2 where name="001 " and id=1 G; Was ist key_len?
Analysieren Sie key_len=4+5*1+2=11, da die Felder nicht null sind, der int-Typ 4 Bytes beträgt und varchar(5) 5 Zeichen + 2 Bytes belegt , ein Zeichen der mit Latin1 codierten Tabelle belegt 1 Byte, also belegt

varchar(5) 7 Bytes. Die Struktur ist wie unten dargestellt


Ergänzung

Da MySQL über einen Abfrageoptimierer verfügt, werden für Abfragen vom Typ wobei a=1 und c=1 die Felder The Die Reihenfolge hat keine Auswirkung, der Abfrageoptimierer führt die Optimierung automatisch durch. wobei c=1 und a=1 auf wobei a=1 und c=1 optimiert wird, es wird jedoch empfohlen, wo zu verwenden a=1 und c=1, zum leichteren Verständnis und zur Abfragepufferung. Da Abfragepufferung und Hashkey-Werte auf der Grundlage von SQL-Anweisungen berechnet werden und die Groß-/Kleinschreibung beachtet wird, sollten Sie beim Schreiben von SQL-Anweisungen darauf achten, diese konsistent zu halten, um zu verhindern, dass dieselbe Abfrage mehrmals zwischengespeichert wird.

Oben finden Sie Einzelheiten zur Berechnung der Indexlänge in MySQL. Weitere verwandte Inhalte finden Sie auf der chinesischen PHP-Website (www.php.cn).


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