Zusammenfassung gängiger Fehler beim Entwurf von MySQL-Tabellen

Fehler 1: Zu viele Datenspalten

Die MySQL-Speicher-Engine-API kopiert Daten zeilengepuffert vom Server zur Speicher-Engine. Der Server dekodiert die Pufferdaten in Datenspalten. Das Konvertieren des Formats des Zeilenpuffers in die Spalten der Datenzeilen-Datenstruktur kann jedoch aufwändig sein. MyISAM verwendet ein festes Zeilenformat, das dem Server entspricht, sodass keine Konvertierung erforderlich ist. Das variable Zeilenformat von MyISAM und das Zeilenformat von InnoDB erfordern jedoch immer eine Konvertierung. Die Kosten für die Konvertierung richten sich nach der Spaltenanzahl. Wenn die Anzahl der Spalten in einer Datentabelle Hunderte übersteigt, führt dies zu einem hohen CPU-Ressourcenverbrauch – selbst wenn nur wenige Spalten verwendet werden. Ich habe einmal einen Artikel gelesen, in dem von einer Mehrsprachenlösung gesprochen wurde, die die vom System unterstützten Sprachen einfach und grob durch entsprechende Spalten darstellte, zum Beispiel:

CREATE TABLE t_multi_language_news (
  ID INT Primärschlüssel,
  Titel_cn VARCHAR(32),
  title_en VARCHAR(32),
  Titel_es VARCHAR(32),
  ...
  content_cn VARVHAR(256),
  content_en VARCHAR(256),
  inhalt_it VARCHAR(256),
);

Dieser Ansatz führt letztendlich zu einer erheblichen Verschlechterung der Leistung, da das System mehr Sprachen unterstützt und die Anzahl der Spalten in der Datentabelle zunimmt. Wenn Sie eine Datentabelle mit mehr als 100 Spalten entwerfen, müssen Sie überlegen, ob Ihr Entwurf sinnvoll ist. **Antwortmethode: **Überlegen Sie zunächst, ob das Design des Unternehmens selbst sinnvoll ist. Wenn eine Entität viele Felder zur Beschreibung benötigt, können Sie die Datentabelle aufteilen und dies tun, indem Sie die Informationstabelle erweitern. Beispielsweise kann der Inhalt von Informationsdatentabellen in eine Informationshaupttabelle und eine Informationsdetailtabelle aufgeteilt werden, da er im Allgemeinen viel Platz einnimmt, aber nicht direkt in der Liste angezeigt wird. In der Haupttabelle werden die in der Liste anzuzeigenden Informationen gespeichert, z. B. Titel, Zeit, Zusammenfassung, Miniaturbild-Anhang-ID usw. In den Informationsdetails können Informationen wie Inhalt, Quelle, Originallink usw. gespeichert werden.

Missverständnis 2: Zu viele gemeinsame Abfragen

MySQL kann maximal 61 Tabellen gleichzeitig abfragen. Einige Designs empfehlen, keine redundanten Felder zu entwerfen, da dies in komplexen Geschäftsprozessen dazu führen würde, dass für Abfragen mehrere Tabellen verbunden werden müssten. Selbst wenn die Anzahl der verknüpften Tabellen weniger als 61 beträgt, verschlechtert sich die Leistung und die Wartung der gesamten SQL-Anweisung wird sehr schwierig. Wenn Sie auf Geschwindigkeit Wert legen, sollten Sie als erstes Designprinzip keine gemeinsamen Abfragen über zu viele Datentabellen in einer Abfrage durchführen, insbesondere bei Szenarien mit hoher Parallelität. **Antwortmethode: **Erstens können Sie bei Feldern, die sich mit Sicherheit nicht ändern, die Reduzierung gemeinsamer Abfragen durch die Verwendung redundanter Felder in Betracht ziehen. Beispielsweise können die Provinzinformationen eines Unternehmens den Provinzcode und den Provinznamen redundant machen, und es besteht keine Notwendigkeit, den Provinznamen über den Provinzcode abzufragen. Zweitens: Wenn Sie wirklich andere Tabellen abfragen müssen, können Sie eine schrittweise Abfragemethode verwenden, um die Datenzusammenstellung über die Anwendung abzuschließen. Diese Methode ist effizienter, wenn viele Datentabellen vorhanden sind, und der Code ist einfacher zu verwalten. Missverständnis 3: Universelle Aufzählung. Beispielsweise das folgende Tabellendesign:

CREATE TABLE t_Länder (
  ...
  Land ENUM('', '1', '2', ..., '45'),
  ...
);

Dies hätte mithilfe einer Wörterbuch-Nachschlagetabelle mit ganzzahligen Schlüsseln implementiert werden können. Wenn aus geschäftlichen Gründen eine Aufzählung hinzugefügt wird, bedeutet dies, dass die gesamte Tabelle mit ALTER TABLE aktualisiert werden muss. Wenn Sie im Anwendungscode eine Nachschlagetabelle verwenden, müssen Sie nur neue Schlüssel-Wert-Paare hinzufügen. **So gehen Sie damit um:** Wenn bekannt ist, dass die Aufzählung unveränderlich ist (z. B. das Geschlecht), dann ist es in Ordnung. Wenn die Zahl erhöht werden kann, sollte dies möglichst über die Bewerbung erfolgen.

Missverständnis 3: Missbrauch von SET statt ENUM

Der Wert einer Aufzählungsspalte vom Typ ENUM in einer Datentabelle kann nur einer aus einer Menge von Werten sein, während die Spalte vom Typ SET einen oder mehrere Werte haben kann. Wenn Sie sicher sind, dass eine Spalte nur einen Wert hat, sollten Sie Aufzählungen anstelle von Sammlungen verwenden. Ein typischer Missbrauchsfall ist etwa das folgende Beispiel:

Tabelle erstellen t_Zahlungsweg (
  ...
  is_default SET('Y', 'N') NICHT NULL DEFAULT 'N',
  ...
);

Offensichtlich ist is_default entweder Y oder N, deshalb sollte hier ENUM verwendet werden. **Lösung: **Überlegen Sie aus geschäftlicher Sicht, ob die Spalte mehrere Werte haben kann. Wenn nur ein optionaler Wert vorhanden ist, verwenden Sie die Aufzählung ENUM.

Mythos 4: Vermeidung von NULL

In vielen Artikeln wurde darüber diskutiert, NULL so weit wie möglich zu vermeiden. Dies ist für die meisten Szenarien ein gutes Design. Wir können Nullwerte durch 0, leere Zeichenfolge, vereinbarten Wert usw. darstellen. Lassen Sie sich davon jedoch nicht täuschen; wenn der Wert selbst bedeutungslos ist, ist die Verwendung von NULL möglicherweise angemessener. Wenn beispielsweise -1 eine bedeutungslose Ganzzahl darstellen würde, würde dies zu kompliziertem Code führen und könnte sogar Fehler verursachen. Beispielsweise das folgende Beispiel:

Tabelle erstellen t_person (
  Geburtstag DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  ...,
);

Es wäre seltsam, den Standardwert eines DATETIME-Typs ausschließlich auf Nullen zu setzen. Angenommen, wir möchten das Durchschnittsalter von Personen berechnen, würde dies unerklärliche Probleme verursachen. In diesem Szenario wird es durch die Verwendung von NULL nicht in die Statistik aufgenommen. Sie können diese Situation vermeiden, indem Sie den MySQL SQL_MODE-Parameter so einstellen, dass die Verwendung bedeutungsloser Daten unterbunden wird. **Bewältigungsmethode: **Beim Entwerfen einer Tabelle können Sie versuchen, NOT NULL zu verwenden, um Nullwerte zu vermeiden, aber seien Sie nicht zu streng. Für einige Felder können Sie auch eine NULL-Spalte verwenden, wenn der Standardwert im Tabellennamen keinen Sinn ergibt oder nicht mit der tatsächlichen Situation übereinstimmt. Sie müssen jedoch darauf achten, in der Indexspalte nicht NULL zu verwenden. In Wirklichkeit ist es unwahrscheinlich, dass die meisten Indexspalten NULL sind.

Mythos 5: Verwendung von Ganzzahlen statt Zeitstempeln

Ich habe bereits erwähnt, wie man das Zeitformat wählt. Tatsächlich verwenden einige Entwickler Ganzzahlen zum Speichern von Zeitstempeln. Sie begründen dies damit, dass dies effizienter ist. In gewissem Sinne verbessert es möglicherweise die Effizienz ein wenig, hilft aber nicht viel, da DATETIME und TIMESTAMP in MySQL als Ganzzahlen gespeichert werden. Wenn Sie Ganzzahlen zum Speichern von Zeiten verwenden, bedeutet dies, dass die Zeitkonvertierung in der Anwendung durchgeführt werden muss oder die SQL-Anweisung die Zeit des angegebenen Felds konvertieren muss und die Vorteile möglicherweise nicht die Kosten überwiegen. **Lösung: **Verwenden Sie DATETIME, um die Zeit so oft wie möglich zu speichern. Wenn Sie die Zeit mit einer Genauigkeit unter einer Sekunde speichern müssen, sollten Sie BIGINT zum Speichern verwenden.

Fehler 6: Maximale Speicherreichweite eines Feldes vergessen

In der Praxis wird beim Entwurf einer Tabelle häufig der Speicherbereich des Datentyps vergessen. Beispielsweise beschränkt TINYINT(2) die Speicherung zweistelliger Ganzzahlen nicht. Der tatsächliche Speicherbereich von TINYINT(2) beträgt -128-127. Speichern Sie Ganzzahlen größer als 255. Dieser Fehler tritt häufig bei der Verwendung von Integer-Typen auf. Beim Einfügen eines Integer-Typs prüft MySQL nicht die tatsächliche Anzahl der Integer-Ziffern, sondern speichert sie entsprechend dem Bereich der entsprechenden Speicherbytes. In diesem Fall werden, wenn Sie nicht aufpassen, bedeutungslose Werte gespeichert. Beispielsweise ist die folgende INSERT-Operation erfolgreich und wir könnten fälschlicherweise annehmen, dass TINYINT(2) nur 2-Bit-Ganzzahlen speichern kann:

Tabelle erstellen t_int_test (
    ID INT Primärschlüssel,
    Zahl TINYINT(2)
);

INSERT INTO t_int_test (ID, Nummer) WERTE (3,123);

Lösung: Führen Sie eine Datenüberprüfung in der Anwendung durch.

Abschluss:

Beim eigentlichen Entwerfen einer Datentabelle müssen Sie neben dem Datentyp jedes Felds auch die Größe des Speicherplatzes berücksichtigen. Für einige häufig verwendete Felder wie Zeit, Titel, Notizen usw. ist es am besten, intern bestimmte Standards festzulegen, und jeder sollte diese Standards einhalten. Durch das Hinzufügen einer Überprüfung können viele Probleme vermieden werden.

Oben finden Sie eine detaillierte Zusammenfassung häufiger MySQL-Datentabellen-Entwurfsfehler. Weitere Informationen zu MySQL-Datentabellen-Entwurfsfehlern finden Sie in den anderen verwandten Artikeln auf 123WORDPRESS.COM!