VARCHAR- und CHAR-TypenVARCHAR und CHAR sind die beiden wichtigsten Zeichenfolgentypen zum Speichern von Zeichen. Da die Implementierung von der Speicher-Engine abhängt, ist es leider schwierig zu erklären, wie diese Zeichenfolgen auf der Festplatte und im Speicher gespeichert werden. Wenn Sie neben den häufig verwendeten InnoDB und MyISAM andere Speicher-Engines verwenden, sollten Sie die Dokumentation der Speicher-Engine sorgfältig lesen. VARCHAR speichert Zeichenfolgen mit variabler Länge und ist der am häufigsten verwendete Zeichendatentyp. VARCHAR benötigt weniger Speicherplatz als Typen mit fester Länge und nutzt so wenig Speicherplatz wie möglich (beispielsweise den von kurzen Zeichenfolgen belegten Speicherplatz). Wenn für MyISAM beim Erstellen einer Tabelle ROW_FORMAT=FIXED angegeben wird, wird ein fester Speicherplatz zum Speichern der Felder verwendet, was zu einer Speicherplatzverschwendung führt. VARCHAR verwendet 1-2 zusätzliche Bytes, um die Länge der Zeichenfolge zu speichern: 1 Byte, wenn die maximale Länge weniger als 255 Bytes beträgt, 2 Bytes, wenn sie mehr beträgt. Daher würde ein lateinischer Zeichensatz VARCHAR(10) 11 Byte Speicher verwenden, während ein VARCHAR(1000) 1002 Byte Speicher verwenden würde. VARCHAR kann die Leistung verbessern, da es Platz spart. Aufgrund der variablen Länge ändert sich jedoch der Speicherplatz der Datenzeile, wenn die Datentabelle aktualisiert wird, was bis zu einem gewissen Grad zusätzlichen Aufwand mit sich bringt. Wenn die Länge der Datenzeile dazu führt, dass der ursprüngliche Speicherort nicht ausreicht, um sie aufzunehmen, handhaben verschiedene Speicher-Engines dies unterschiedlich. Beispielsweise kann MyISAM fragmentierte Datenzeilen generieren, während InnoDB zum Speichern aktualisierter Datenzeilen eine Datenträgerauslagerung erfordert. Im Allgemeinen ist die Verwendung von VARCHAR kosteneffizient, wenn die größte Spaltenlänge viel größer als die durchschnittliche Länge ist (z. B. ein optionales Memofeld) und die Aktualisierungshäufigkeit gering ist, sodass Fragmentierung kein Problem darstellt. Es ist zu beachten, dass bei Verwendung des UTF-8-Zeichensatzes die tatsächlich gespeicherte Bytelänge durch das Zeichen bestimmt wird. Für Chinesisch ist utf8mb4 der empfohlene Speicherzeichensatz. Die Länge des CHAR-Typs ist festgelegt und MySQL weist jedem Feld ausreichend Speicherplatz zu. Beim Speichern von Werten vom Typ CHAR entfernt MySQL alle folgenden zusätzlichen Nullzeichen. Werte werden zu Vergleichszwecken mithilfe von Nullzeichen ausgerichtet. Bei kurzen Strings ist CHAR vorteilhafter und wenn alle Werte etwa gleich lang sind, kann CHAR verwendet werden. Beispielsweise ist es sinnvoller, CHAR beim Speichern des MD5-Werts eines Benutzerkennworts zu verwenden, da die Länge von MD5 immer fest ist. Gleichzeitig ist CHAR für Datentypen, deren Feldwerte sich häufig ändern, vorteilhafter als VARCHAR, da CHAR keine Fragmentierung erzeugt. Bei sehr kurzen Datenspalten ist die Verwendung von CHAR effizienter als die von VARCHAR. Beispielsweise erfordert die Verwendung von CHAR(1) zum Speichern logischer Werte Y und N nur 1 Byte, während VARCHAR 2 Bytes benötigt. Es mag sich seltsam anfühlen, das Nullzeichen zu entfernen. Nehmen wir ein Beispiel: Tabelle erstellen t_char_varchar_test ( ID INT Primärschlüssel, char_col CHAR(10), varchar_col VARCHAR(10) ); INSERT INTO t_char_varchar_test WERTE (1, 'Zeichenfolge1', 'Zeichenfolge1'), (2, ' Zeichenfolge2', ' Zeichenfolge2'), (3, 'Zeichenfolge3', 'Zeichenfolge3'); Nach dem Einfügen der obigen Ergebnisse in die Datentabelle werden die führenden Leerzeichen in string2 nicht entfernt, aber bei Verwendung des CHAR-Speichertyps werden die nachfolgenden Leerzeichen in string3 entfernt. Verwenden Sie die SQL-Abfrageergebnisse, um Folgendes zu überprüfen: SELECT CONCAT("'", char_col, "'"), CONCAT("'", varchar_col, "'") VON t_char_varchar_test WO 1 Die Ergebnisse sind wie folgt. Sie können sehen, dass das Leerzeichen nach string3 vom Typ CHAR entfernt wird, aber nicht vom Typ VARCHAR. Diese Situation verursacht in den meisten Fällen keine Probleme. In der Praxis wird die Trim-Funktion in Anwendungen häufig verwendet, um die leeren Zeichen an beiden Enden zu entfernen. Wenn Sie jedoch wirklich Leerzeichen speichern müssen, müssen Sie darauf achten, nicht den CHAR-Typ zu verwenden: Wie Daten gespeichert werden, wird durch die Speicher-Engine bestimmt, und Speicher-Engines verarbeiten Daten mit fester und variabler Länge unterschiedlich. Die Speicher-Engine verwendet Zeilen mit fester Größe und muss daher den größtmöglichen Speicherplatz zuweisen – auch wenn die Datenlänge variabel ist. Die Zeichenfolgenausrichtung und die Null-Abschneidung werden jedoch vom MySQL-Server durchgeführt und sind daher für alle Speicher-Engines gleich. Ähnlich wie CHAR und VARCHAR sind BINARY und VARBINARY, die zum Speichern binärer Byte-Zeichen verwendet werden. BINARY wird anhand des Byte-Werts des Zeichens 0 ausgerichtet und der Wert wird beim Abrufen nicht abgeschnitten. Wenn Sie den Bytewert eines Zeichens anstelle des Zeichens verwenden müssen, ist es effizienter, BINARY zu verwenden, da Sie einerseits beim Vergleichen die Groß-/Kleinschreibung nicht berücksichtigen müssen und MySQL andererseits immer nur ein Byte auf einmal vergleicht. Abschluss:Beim tatsächlichen Entwurf von Datentabellen wird in den meisten Fällen VARCHAR gewählt, aber VARCHAR erfordert zusätzliche 1–2 Bytes, um die Zeichenfolgenlänge zu speichern. Es ist zu beachten, dass es am besten ist, die maximale Länge des Felds in der Anwendung zu begrenzen, damit die Datentabelle zur Verbesserung der Effizienz den kürzestmöglichen VARCHAR verwenden kann. Gleichzeitig wird für Zeichentypen mit fester Länge, sehr kurzer Länge oder sehr kleinen Längenänderungen empfohlen, die Speicherklasse CHAR zu verwenden, um die Speichereffizienz zu verbessern. Oben sind die Details zur Auswahl von MySQL CHAR und VARCHAR aufgeführt. Weitere Informationen zu MySQL CHAR und VARCHAR finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM! Das könnte Sie auch interessieren:
|
<<: Vue3 verwendet Axios Interceptor zum Drucken von Front-End-Protokollen
>>: Docker+Gitlab+Jenkins erstellt automatisierte Bereitstellung von Grund auf
CSS-Schreibreihenfolge 1. Positionsattribute (Pos...
Methode 1: Hostnamectl-Änderung Schritt 1 Überprü...
Inhaltsverzeichnis Überblick Die Rolle des Revers...
1. Overlay-Übersicht Overlay bedeutet Überlagerun...
Problembeschreibung Als ich heute den Seitenstil ...
Die MySQL-Installation ist in eine Installationsv...
Installieren Sie das SSH-Tool 1. Öffnen Sie das T...
Prinzip Setzen Sie beim Schweben einen Schatten a...
Inhaltsverzeichnis verifizieren: Kombiniert mit d...
1. Verwenden Sie den folgenden Befehl, um das SSH...
Vorwort Einfach ausgedrückt ist tcpdump ein Paket...
Vorne geschrieben Ich weiß nicht, wer als Erster ...
In diesem Artikel wird hauptsächlich der Beispiel...
Ⅰ. Problembeschreibung: Verwenden Sie CSS, um kon...
In diesem Artikel wird der spezifische Code von J...