Warum ein VARCHAR-Feld anstelle von TEXT in MySQL verwenden

Hintergrund

Beim Speichern eines Segments serialisierter Daten ungewisser Länge in einer Datenbank entwerfen viele Leute das Feld als VARCHAR(2000) im Tabellenschema.

Aber wenn die Länge ungewiss ist, warum nicht den Typ TEXT verwenden? Einige sagen: TEXT beeinträchtigt die Abfrageleistung.

Ist das wirklich der Grund? Dieser Artikel wird das untersuchen:

Was ist TEXT

TEXT ist ein Datentyp variabler Länge in MySQL, einschließlich TINYTEXT, TEXT, MEDIUMTEXT und LONGTEXT. Sie werden typischerweise verwendet, um große Mengen an Textdaten zu speichern, mit den folgenden Speicherbegrenzungen:

• TINYTEXT: 0 - 255 Bytes
• TEXT: 0 - 65.535 Bytes
• MEDIUMTEXT: 0 - 16.777.215 Bytes
• LONGTEXT: 0 - 4.294.967.295 Bytes

Wie TEXT gespeichert wird

Jeder BLOB- oder TEXT-Wert wird intern durch ein separat zugewiesenes Objekt dargestellt, während andere Datentypen Speicherplatz haben, der einmal pro Spalte zugewiesen wird, wenn die Tabelle geöffnet wird.

Beim Speichern von Daten vom Typ String codiert InnoDB Felder fester Länge von 768 Byte oder mehr als Felder variabler Länge und speichert sie in Overflow-Seiten. Daten, die kleiner als 768 Byte sind, werden direkt in der Datenzeile gespeichert. Daher sollte man bei der Verwendung anderer String-Typen vermeiden, Daten zu speichern, die 768 Byte oder größer sind.

Einschränkungen von TEXT

• TEXT kann keinen Standardwert haben.
• Beim Indizieren eines TEXT-Feldes muss eine Präfixlänge angegeben werden.
• Beim Vergleichen von Indexeinträgen werden nachfolgende Leerzeichen aufgefüllt. Wenn ein eindeutiger Index erforderlich ist, kann dies zu Fehlern durch doppelte Schlüssel führen.
• TEXT-Felder können besonders lang sein. Beim Sortieren werden nur die ersten max_sort_length Bytes (Standard ist 1024) verwendet. Dieser Wert kann durch Ändern der Variablen angepasst werden:

-- View max_sort_length
SELECT @@max_sort_length;

-- Set max_sort_length
SET max_sort_length = 2048;

• Bei der Verarbeitung mit temporären Tabellen verwendet der Server Tabellen auf der Festplatte anstatt im Speicher, da die MEMORY-Speicherengine den Typ TEXT nicht unterstützt.

• Die Größe eines TEXT-Objekts wird durch seinen Typ bestimmt, aber die tatsächlich übertragbare maximale Größe wird durch den verfügbaren Inhalts- und Kommunikationspufferspeicher begrenzt. Dies kann durch Ändern der Variablen max_allowed_packet angepasst werden:

-- View max_allowed_packet
SELECT @@max_allowed_packet;

-- Set max_allowed_packet
SET max_allowed_packet = 67108864;

Fazit

TEXT kann verwendet werden, um große Mengen an Textdaten zu speichern. Aus verschiedenen Gründen wird jedoch nicht empfohlen, TEXT zu verwenden:

Leistungsprobleme

• TEXT wird intern als ein separat zugewiesenes Objekt dargestellt, was zusätzliche Operationen und Ressourcenverbrauch während der Speicherung und des Abrufs erfordert.
• Wenn ein TEXT-Feld besonders groß ist, kann das Lesen den Speicherdruck erhöhen, was die Gesamtleistung des Systems beeinträchtigt.
• Die MEMORY-Speicherengine unterstützt TEXT nicht, sodass bei der Verwendung temporärer Tabellen Daten aus TEXT-Feldern von der Festplatte anstatt direkt aus dem Speicher gelesen werden.

Indexierungsbeschränkungen

Indizes können die Abfrageleistung verbessern, aber die Indizierung von TEXT-Feldern ist mit bestimmten Einschränkungen und Komplexität verbunden:

• Bei Verwendung als eindeutiger Index kann dies zu Fehlern durch doppelte Schlüssel führen.
• Das Erstellen von Volltextindizes erfordert zusätzliche Berechnungen und Speicherplatz, um sie zu verwalten. Wenn das TEXT-Feld zu groß ist, kann dies die Leistung negativ beeinflussen.

Daher ist es ratsam, die Verwendung des Typs TEXT zu vermeiden beim Entwurf von Tabellenschemata. Wenn er verwendet werden muss, sollten Sie die folgenden Ansätze in Betracht ziehen:

• Trennen Sie TEXT-Felder in unabhängige Tabellen und verknüpfen Sie sie über den Primärschlüssel mit der Haupttabelle.
• Vermeiden Sie es, TEXT-Felder zu lesen, es sei denn, dies ist erforderlich – verwenden Sie beispielsweise nicht SELECT *.
• Für große Felder sollten Sie in der Speicherung im OSS (Object Storage Service) in Betracht ziehen.

---

Wir sind Leapcell, Ihre erste Wahl für das Hosting von Backend-Projekten.

Leapcell ist die Serverless-Plattform der nächsten Generation für Webhosting, asynchrone Aufgaben und Redis:

Multi-Sprachen-Unterstützung

• Entwickeln Sie mit Node.js, Python, Go oder Rust.

Stellen Sie unbegrenzt Projekte kostenlos bereit

• Zahlen Sie nur für die Nutzung - keine Anfragen, keine Gebühren.

Unschlagbare Kosteneffizienz

• Pay-as-you-go ohne Leerlaufgebühren.
• Beispiel: 25 US-Dollar unterstützen 6,94 Millionen Anfragen bei einer durchschnittlichen Antwortzeit von 60 ms.

Optimierte Entwicklererfahrung

• Intuitive Benutzeroberfläche für mühelose Einrichtung.
• Vollständig automatisierte CI/CD-Pipelines und GitOps-Integration.
• Echtzeitmetriken und -protokollierung für umsetzbare Erkenntnisse.

Mühelose Skalierbarkeit und hohe Leistung

• Auto-Skalierung zur mühelosen Bewältigung hoher Parallelität.
• Null Betriebsaufwand - konzentrieren Sie sich einfach auf das Bauen.

Erfahren Sie mehr in der Dokumentation!

Folgen Sie uns auf X: @LeapcellHQ