Detaillierte Erklärung der MySQL 30-Militärregeln

1. Grundlegende Spezifikationen

(1) Es muss die InnoDB-Speicher-Engine verwendet werden. Interpretation: Unterstützt Transaktionen, Sperren auf Zeilenebene, bessere Parallelitätsleistung, CPU- und Speichercache-Seitenoptimierung, um eine höhere Ressourcenauslastung zu erreichen

(2) Für die Interpretation muss der Zeichensatz UTF8 verwendet werden: Unicode, keine Transkodierung erforderlich, keine Gefahr von Zeichenverfälschungen und platzsparend

(3) Datentabellen und Datenfelder müssen auf Chinesisch kommentiert werden: Wer weiß nach N Jahren, wofür die Felder r1, r2 und r3 sind?

(4) Verbot der Verwendung von gespeicherten Prozeduren, Ansichten, Triggern und Ereignissen
Interpretation: Für Internetunternehmen mit großen Datenmengen und hoher Parallelität besteht die architektonische Designidee darin, „die Datenbank-CPU freizugeben und die Berechnung auf die Serviceebene zu übertragen“. Bei hoher Parallelität verlangsamen diese Funktionen wahrscheinlich die Datenbank. Das Platzieren der Geschäftslogik in der Serviceebene bietet eine bessere Skalierbarkeit und kann leicht „eine Leistungssteigerung durch Hinzufügen von Maschinen“ erreichen. Datenbanken sind gut in der Speicherung und Indizierung, daher sollte die CPU-Berechnung nach oben verschoben werden

(5) Speichern Sie keine großen Dateien oder großen Fotos. Interpretation: Warum sollte man die Datenbank etwas tun lassen, was sie nicht gut kann? Große Dateien und Fotos werden im Dateisystem gespeichert. Es ist besser, URIs in der Datenbank zu speichern

2. Benennungsstandards

(6) Für die Verbindung mit der Datenbank ist nur der Intranet-Domänenname zulässig, nicht jedoch die IP-Adresse.

(7) Der Domänenname der Online-Umgebung, der Entwicklungsumgebung und der Testumgebungsdatenbank im Intranet folgt der Namenskonvention Firmenname: xxx
Online-Umgebung: dj.xxx.db
Entwicklungsumgebung: dj.xxx.rdb
Testumgebung: dj.xxx.tdb
Der Name der Slave-Datenbank wird mit -s und der Name der Standby-Datenbank mit -ss ergänzt. Online-Slave-Datenbank: dj.xxx-s.db
Online-Backup-Datenbank: dj.xxx-sss.db

(8) Datenbankname, Tabellenname, Feldname: Kleinbuchstaben, Unterstreichungsstil, nicht mehr als 32 Zeichen, muss selbsterklärend sein und die Kombination von Pinyin und Englisch ist verboten

(9) Tabellenname t_xxx, nicht eindeutiger Indexname idx_xxx, eindeutiger Indexname uniq_xxx

3. Tischdesign-Spezifikationen

(10) Die Anzahl der Einzelinstanztabellen muss kleiner als 500 sein.

(11) Die Anzahl der Spalten in einer einzelnen Tabelle muss weniger als 30 betragen

(12) Die Tabelle muss einen Primärschlüssel haben, beispielsweise eine Auto-Increment-Primärschlüsselinterpretation:
a) Durch das Inkrementieren des Primärschlüssels und das Schreiben von Datenzeilen kann die Einfügeleistung verbessert, Seitenaufteilungen vermieden, Tabellenfragmentierung verringert und die Speicherplatz- und Speichernutzung verbessert werden
b) Der Primärschlüssel sollte einen kürzeren Datentyp haben. Der normale Index der Innodb-Engine speichert den Primärschlüsselwert. Ein kürzerer Datentyp kann den Speicherplatz des Indexes effektiv reduzieren und die Cache-Effizienz des Indexes verbessern.
c) Das Löschen einer Tabelle ohne Primärschlüssel führt dazu, dass die Standby-Datenbank in einer Master-Slave-Architektur im Zeilenmodus blockiert wird.

(13) Fremdschlüssel sind verboten. Wenn Integritätsbeschränkungen für Fremdschlüssel bestehen, ist eine Anwendungskontrolle erforderlich: Fremdschlüssel verursachen eine Kopplung zwischen Tabellen. Aktualisierungs- und Löschvorgänge betreffen verwandte Tabellen, was die SQL-Leistung erheblich beeinträchtigt und sogar zu Deadlocks führen kann. Hohe Parallelität kann leicht zu Datenbankleistungsproblemen führen. In Big Data- und hochparallelitätsbasierten Geschäftsszenarien hat die Datenbankleistung höchste Priorität.

4. Felddesignspezifikationen

(14) Das Feld muss als NOT NULL definiert werden, und es muss ein Standardwert angegeben werden:
a) Null-Spalten machen Indizes/Indexstatistiken/Wertvergleiche komplizierter und für MySQL schwieriger zu optimieren
b) Null Dieser Datentyp muss in MySQL speziell verarbeitet werden, was die Komplexität der Datenbankdatensatzverarbeitung erhöht. Unter den gleichen Bedingungen wird die Datenbankverarbeitungsleistung erheblich reduziert, wenn die Tabelle viele leere Felder enthält.
c) Nullwerte benötigen mehr Speicherplatz. Die Nullspalte in jeder Zeile der Tabelle oder des Index erfordert zusätzlichen Speicherplatz zur Identifizierung
d) Beim Umgang mit Null kann nur „ist null“ oder „ist nicht null“ verwendet werden und die Operationssymbole wie =, in, <, <>, != und nicht in können nicht verwendet werden. Beispiel: where name!='shenjian', wenn es einen Datensatz mit einem Nullwert für den Namen gibt, wird das Abfrageergebnis den Datensatz mit einem Nullwert für den Namen nicht enthalten

(15) Verbieten Sie die Verwendung von TEXT- und BLOB-Typen. Interpretation: Dadurch wird mehr Festplatten- und Speicherplatz verschwendet. Unnötige Abfragen großer Felder eliminieren Hot Data, was zu einem starken Rückgang der Speichertrefferrate führt und die Datenbankleistung beeinträchtigt.

(16) Verwenden Sie keine Dezimalzahlen, um Geld anzugeben. Interpretation: Verwenden Sie Ganzzahlen. Dezimalzahlen können leicht dazu führen, dass Geld nicht übereinstimmt.

(17) Für die Speicherung von Mobiltelefonnummern muss varchar(20) verwendet werden. Interpretation:
a) Bei Ortsvorwahlen oder Ländervorwahlen kann +-() erscheinen
b) Können mit Mobiltelefonnummern mathematische Operationen durchgeführt werden?
c) VARCHAR kann Fuzzy-Abfragen unterstützen, zum Beispiel: wie „138 %“

(18) ENUM ist verboten. Statt dessen kann TINYINT verwendet werden:
a) Das Hinzufügen neuer ENUM-Werte erfordert DDL-Operationen
b) Der eigentliche interne Speicher von ENUM besteht aus Ganzzahlen. Dachten Sie, Sie hätten einen String definiert?

5. Spezifikationen für das Indexdesign

(19) Es wird empfohlen, die Anzahl der Indizes in einer einzelnen Tabelle auf weniger als 5 zu begrenzen.

(20) Die Anzahl der Felder in einem einzelnen Index darf 5 nicht überschreiten. Interpretation: Bei mehr als 5 Feldern ist eine effektive Datenfilterung nicht mehr möglich.

(21) Es ist verboten, Indexinterpretationen für Attribute zu erstellen, die sehr häufig aktualisiert werden und eine geringe Differenzierung aufweisen:
a) Durch Updates wird der B+-Baum geändert und die Indizierung häufig aktualisierter Felder verringert die Datenbankleistung erheblich.
b) Für Attribute wie „Geschlecht“, die nicht sehr diskriminierend sind, ist es sinnlos, einen Index zu erstellen. Dadurch können Daten nicht effektiv gefiltert werden und die Leistung ist ähnlich der eines vollständigen Tabellenscans.

(22) Bei der Erstellung eines kombinierten Indexes müssen die Felder mit hoher Trennschärfe an den Anfang gestellt werden. Interpretation: Dadurch können die Daten effektiver gefiltert werden.

6. SQL-Nutzungsspezifikationen

(23) Verwenden Sie kein SELECT *. Es werden nur die erforderlichen Felder abgerufen. Die Spaltenattribute müssen angezeigt werden:
a) Das Lesen unnötiger Spalten erhöht den CPU-, IO- und NET-Verbrauch
b) Abdeckungsindizes können nicht effektiv genutzt werden
c) Die Verwendung von SELECT * ist anfällig für Programmfehler nach dem Hinzufügen oder Löschen von Feldern

(24) Die Verwendung von INSERT INTO t_xxx VALUES(xxx) ist verboten. Die Attribute der angegebenen eingefügten Spalten müssen angezeigt werden. Interpretation: Nach dem Hinzufügen oder Löschen von Feldern können leicht Programmfehler auftreten.

(25) Implizite Attributkonvertierung ist verboten. Interpretation: SELECT uid FROM t_user WHERE phone=13812345678 führt zu einem vollständigen Tabellenscan und wird den Telefonindex nicht finden. Raten Sie mal, warum? (Dieses Online-Problem ist mehr als einmal aufgetreten)

(26) Es ist verboten, Funktionen oder Ausdrücke auf die Attribute der WHERE-Bedingung anzuwenden. Interpretation: SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' führt zu einem vollständigen Tabellenscan. Die korrekte Schreibweise lautet: SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')

(27) Negative Anfragen und Fuzzy-Anfragen, die mit % beginnen, sind verboten:
a) Negative Abfragebedingungen: NOT, !=, <>, !<, !>, NOT IN, NOT LIKE usw. führen zu einem vollständigen Tabellenscan
b) Fuzzy-Abfragen, die mit % beginnen, führen zu einem vollständigen Tabellenscan

(28) JOIN-Abfragen und die Interpretation von Unterabfragen für große Tabellen sind verboten: Es werden temporäre Tabellen generiert, die mehr Speicher und CPU verbrauchen und die Datenbankleistung stark beeinträchtigen

(29) OR-Bedingungen sind verboten und müssen in IN-Abfragen geändert werden. Interpretation: OR-Abfragen in alten MySQL-Versionen können den Index nicht erreichen. Selbst wenn sie den Index erreichen können, warum sollte die Datenbank mehr CPU verbrauchen, um die Abfrageoptimierung zu unterstützen?

(30) Die Anwendung muss SQL-Ausnahmen erfassen und entsprechend behandeln

Das Obige ist der vollständige Inhalt dieses Artikels. Ich hoffe, er wird für jedermanns Studium hilfreich sein. Ich hoffe auch, dass jeder 123WORDPRESS.COM unterstützen wird.