Die umfassendste Weitergabe von MySQL-Nutzungsspezifikationen in der Geschichte

[Verwandte Lernempfehlungen: MySQL-Tutorial]

In letzter Zeit gab es viele datenbankbezogene Vorgänge, und die vorhandenen Spezifikationen des Unternehmens sind nicht allzu umfassend. Ich habe einige Standardverwendungen für meinen eigenen Gebrauch zusammengestellt Bitte korrigieren Sie mich anhand der entsprechenden Angaben verschiedener Experten im Internet.

Datenbankumgebung

dev: Entwicklungsumgebung

Die Entwicklung kann lesen und schreiben und die Tabellenstruktur ändern. Entwickler können die Tabellenstruktur und die darin enthaltenen Daten nach Belieben ändern, müssen jedoch sicherstellen, dass andere Entwicklungskollegen davon nicht betroffen sind.

Test: Die Testumgebung

ist für Entwickler lesbar und beschreibbar, und Entwickler können die Tabellenstruktur mithilfe von Tools ändern.

online: Online-Umgebung

Entwickler dürfen Datenbankvorgänge nicht direkt in der Online-Umgebung ausführen. Wenn Vorgänge erforderlich sind, müssen sie den DBA finden, um Vorgänge durchzuführen und entsprechende Aufzeichnungen zu erstellen.

Das Hauptproblem besteht darin, dass die Benutzerberechtigungen, die dem MySQL-Server in jeder Umgebung entsprechen, klar unterteilt, identifizierbar und in der Lage sein müssen, Geschäftsszenarien usw. spezifisch zu unterscheiden.

Namenskonvention

Grundlegende Namensregeln

• Verwenden Sie aussagekräftige englische Wörter, getrennt durch Unterstriche in der Mitte. (Verwenden Sie kein Pinyin)
• Verwenden Sie nur englische Buchstaben, Zahlen und Unterstriche und beginnen Sie mit einem englischen Buchstaben.
• Verwenden Sie für Bibliotheken, Tabellen und Felder ausschließlich Kleinbuchstaben und verwenden Sie keine Kamelbuchstaben für die Benennung.
• Vermeiden Sie die Verwendung reservierter Wörter von ORACLE und MySQL, wie z. B. desc, und Schlüsselwörtern, wie z. B. index.
• Der Name darf nicht länger als 32 Zeichen sein. Es wird empfohlen, Substantive anstelle von Verben zu verwenden.
• Alle Datenbanken und Datentabellen müssen Präfixe verwenden. Temporären Datenbank- und Tabellennamen müssen tmp und vorangestellt werden mit dem Suffix „Datum“
• Backup-Bibliotheken und -Tabellen müssen mit dem Präfix „bak“ und dem Suffix „Datum“ versehen werden

Warum werden Bibliotheken, Tabellen und Felder alle in Kleinbuchstaben geschrieben?

In MySQL entsprechen Datenbanken und Tabellen Verzeichnissen und Dateien unter diesen Verzeichnissen. Daher bestimmt die Sensibilität des Betriebssystems die Groß-/Kleinschreibung bei der Benennung von Datenbanken und Tabellen.

Unter Windows wird die Groß-/Kleinschreibung nicht beachtet.

• Groß-/Kleinschreibung unter Linux
• Bei Datenbanknamen und Tabellennamen wird die Groß-/Kleinschreibung strikt beachtet;
• Spaltennamen und Spaltenaliase werden in allen Fällen ignoriert Groß- und Kleinschreibung beachten;
• Wie kann das Problem gelöst werden, wenn die Benennung in Groß- und Kleinschreibung festgelegt wurde? Sie müssen Lower_case_table_names = 1 zur MySQL-Konfigurationsdatei my.ini hinzufügen.
• Tabellenbenennung
• 
  
Tabellen im selben Modul sollten so weit wie möglich das gleiche Präfix verwenden und die Tabellennamen sollten die Bedeutung so gut wie möglich ausdrücken. Alle Protokolltabellen beginnen mit log_

Feldnamen

Englische Wörter oder Abkürzungen, die ihre tatsächliche Bedeutung ausdrücken. Feldern mit boolescher Bedeutung wird is_ vorangestellt, gefolgt vom Partizip Perfekt des Verbs.

Felder mit derselben Bedeutung zwischen Tabellen sollten denselben Namen haben. Felder mit derselben Bedeutung zwischen Tabellen werden mit dem Namen „Tabellenname_Feldname“ abzüglich des Modulpräfixes benannt.

Fremdschlüsselfelder verwenden Tabellenname_Feldname, um ihre Zuordnung anzuzeigen.

• Der Primärschlüssel einer Tabelle ist im Allgemeinen eine ID, ein automatisch inkrementierender Typ, und die Fremdschlüssel anderer Tabellen werden in der Form xxx_id ausgedrückt.
• Indexbenennung

Ein nicht eindeutiger Index muss nach „idx_field name_field name[_field name]“ benannt werden.

Eindeutiger Index muss nach „uniq_field name_field name [_field name]“ benannt werden

Einschränkungsbenennung
• 
  Primärschlüsseleinschränkung: pk_table-Name.

Eindeutige Einschränkung: uk_table name_field name. (Die Anwendung muss gleichzeitig über eine Eindeutigkeitsprüfungslogik verfügen.)

Tabellendesign-Spezifikationen
• Die Tabellen-Engine hängt vom tatsächlichen Anwendungsszenario ab; für Protokoll- und Berichtstabellen sowie Tabellen im Zusammenhang mit Transaktionen wird empfohlen , Audits und Beträge werden empfohlen. Wenn keine Erklärung vorliegt, wird beim Erstellen der Tabelle die Innodb-Engine verwendet. Der Standardzeichensatz utf8mb4 wird verwendet, und die Datenbanksortierregel lautet utf8mb4_general_ci (Da die Datenbankdefinition den Standard verwendet, kann die Datentabelle nicht mehr verwendet werden definiert, aber aus Sicherheitsgründen wird empfohlen, sie alle zu schreiben.
  

Warum wählen Sie nicht utf8 als Zeichensatz und utf8_general_ci als Sortierregel? Platzhalter von 4 Bytes, damit das Back-End-Projekt die Emoji-Eingabe durch den Client vollständig unterstützt. Für Situationen, in denen die Zeichenkodierung auf utf8mb4 eingestellt ist Emoji-Daten können nach der obigen Konfiguration nicht normal eingefügt werden. Der Verbindungszeichensatz muss im Code Alle Tabellen und Felder sollten das Kommentarspaltenattribut verwenden, um die wahre Bedeutung der Tabelle und des Felds zu beschreiben Da es sich um einen Aufzählungswert handelt, wird empfohlen, den gesamten im Feld verwendeten Inhalt zu definieren.

Wenn es keine Erklärung gibt, muss das Feld ein Primärschlüssel sein und darf nicht automatisch übertragen werden Daten als Kontext innerhalb einer Nicht-Transaktion. Es ist verboten, den Typ varchar als Primärschlüssel-Anweisungsdesign zu verwenden.

Wenn es keine Erklärung gibt, muss die Tabelle die Felder „create_time“ und „modify_time“ enthalten, das heißt, die Tabelle muss Felder enthalten, die die Erstellungszeit und die Änderungszeit aufzeichnen.

Wenn es keine Erklärung gibt, muss die Tabelle is_del enthalten Wird verwendet, um anzuzeigen, ob die Daten gelöscht wurden. Eine physische Entfernung ist grundsätzlich nicht zulässig.

• Verwenden Sie so wenig Speicherplatz wie möglich, um Daten in einem Feld zu speichern.
• Wenn Sie int verwenden können, verwenden Sie weder char noch varchar.
• Wenn Sie tinyint verwenden können, verwenden Sie nicht int.
• Verwenden Sie UNSIGNED zum Speichern nicht negative Werte.
• Es wird nicht empfohlen, die Typen ENUM und SET zu verwenden. Verwenden Sie stattdessen TINYINT Anstelle von FLOAT und DOUBLE
• Zeitfelder verwenden außer in besonderen Fällen int, um unix_timestamp aufzuzeichnen.
• Verwenden Sie den Typ YEAR, um das Jahr zu speichern.
• Speicherdatum verwendet den Typ DATE.
• Es wird empfohlen, den Typ TIMESTAMP zum Speichern der Zeit (sekundengenau) zu verwenden, da TIMESTAMP 4 Bytes und DATETIME 8 Bytes verwendet.
• Es wird empfohlen, INT UNSIGNED zum Speichern von IPV4 zu verwenden.
• Verwenden Sie möglichst nicht die Typen TEXT und BLOB.
• Es ist verboten, VARBINARY und BLOB zum Speichern von Bildern, Dateien usw. in der Datenbank zu verwenden. Es wird empfohlen, andere Speichermethoden (TFS/SFS) zu verwenden. MySQL speichert nur Zeigerinformationen.
• Die Größe eines einzelnen Datensatzes darf 8 KB nicht überschreiten (Spaltenlänge (Chinesisch)_3 (UTF8) + Spaltenlänge (Englisch)_1)
• Was ist der Unterschied zwischen Datum/Uhrzeit und Zeitstempel?

Ähnliche Punkte:

Das Anzeigeformat der TIMESTAMP-Spalte ist das gleiche wie das der DATETIME-Spalte. Die Anzeigebreite ist auf 19 Zeichen festgelegt und das Format ist JJJJ-MM-TT HH:MM:SS.

Unterschied:

TIMESTAMP

4 Bytes Speicher, Zeitbereich: 1970-01-01 08:00:01 ~ 2038-01-19 11:14:07 Der Wert wird im UTC-Format unter Berücksichtigung der Zeitzone gespeichert Konvertierung: Beim Speichern die aktuelle Zeitzone konvertieren und beim Abrufen wieder in die aktuelle Zeitzone konvertieren.

Datum/Uhrzeit wird in 8 Bytes gespeichert, Zeitbereich: 1000-01-01 00:00:00 ~ 9999-12-31 23:59:59

• Tatsächliche Formatspeicherung, unabhängig von der Zeitzone
• 
  
Wie TIMESTAMP Automatisch zugewiesene Eigenschaften verwenden?

Legen Sie die aktuelle Zeit als Standardwert von ts fest: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP. Wenn die Zeile aktualisiert wird, aktualisieren Sie den Wert von ts: ts TIMESTAMP DEFAULT 0 ON UPDATE CURRENT_TIMESTAMP. Sie können 1 und 2 kombinieren: ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP.

Wie verwende ich INT UNSIGNED zum Speichern von IP?

Verwenden Sie INT UNSIGNED anstelle von char(15), um die IPv4-Adresse zu speichern, und verwenden Sie die MySQL-Funktionen inet_ntoa und inet_aton zur Konvertierung. IPv6-Adressen verfügen derzeit nicht über eine Konvertierungsfunktion und müssen mit DECIMAL oder zwei bigINTs gespeichert werden.

Wenn keine Kommentare vorhanden sind, werden alle Felder auf NOT NULL gesetzt und Standardwerte gesetzt.

Es ist verboten, Klartext-Passwörter in der Datenbank zu speichern.

• Wenn keine Kommentare vorhanden sind, werden alle booleschen Felder, wie z Als is_hot und is_deleted muss ein Standardwert auf 0 gesetzt werden.
• Wenn kein Kommentar vorhanden ist, wird das Sortierfeld order_id standardmäßig in absteigender Reihenfolge im Programm angeordnet.
• Der Ganzzahldefinition wird keine Länge hinzugefügt. Wie zum Beispiel die Verwendung von INT anstelle von INT[4]
• 
  
INT [M], was bedeutet der M-Wert?

Beachten Sie, dass die Zahl hinter den numerischen Typklammern nur die Breite angibt und nichts mit der Speicherreichweite zu tun hat. Viele Leute denken, dass die Wertebereiche von INT(4) und INT(10) (-9999 bis 9999) bzw. (-9999999999) sind. Dieses Verständnis ist falsch. Wenn der M-Wert in der Ganzzahl in Kombination mit dem ZEROFILL-Attribut verwendet wird, können die Spaltenwerte tatsächlich die gleiche Breite haben. Unabhängig vom Wert von M in INT[M] ist der Wertebereich immer noch (-2147483648 bis 2147483647 bei Vorzeichen) (0 bis 4294967295 bei Vorzeichen). Die Anzeigebreite schränkt weder den Wertebereich ein, der innerhalb der Spalte gespeichert werden kann, noch die Anzeige von Werten, die die angegebene Spaltenbreite überschreiten. Bei Verwendung in Verbindung mit dem optionalen erweiterten Attribut ZEROFILL werden die standardmäßigen zusätzlichen Leerzeichen durch Nullen ersetzt. Beispiel: Für eine Spalte, die als INT(5) ZEROFILL deklariert ist, wird der Wert 4 als 00004 abgerufen. Bitte beachten Sie, dass MySQL bei der Generierung temporärer Tabellen für komplexe Verknüpfungen auf Probleme stößt, wenn Sie einen Wert in einer Integer-Spalte speichern, der die Anzeigebreite überschreitet, da MySQL in diesen Fällen davon ausgeht, dass die Daten zur ursprünglichen Spaltenbreite passen Eine numerische Spalte, MySQL fügt der Spalte automatisch das UNSIGNED-Attribut hinzu.

Verwenden Sie VARBINARY, um Zeichenfolgen variabler Länge zu speichern, bei denen zwischen Groß- und Kleinschreibung unterschieden wird.

Wann sollte CHAR und wann VARCHAR verwendet werden?

CHAR- und VARCHAR-Typen sind ähnlich, werden jedoch unterschiedlich gespeichert und abgerufen. Sie unterscheiden sich auch hinsichtlich ihrer maximalen Länge und ob nachgestellte Leerzeichen erhalten bleiben. Die für die Typen CHAR und VARCHAR deklarierte Länge stellt die maximale Anzahl von Zeichen dar, die Sie speichern möchten. CHAR(30) kann beispielsweise 30 Zeichen belegen. Die Länge der CHAR-Spalte ist auf die Länge festgelegt, die beim Erstellen der Tabelle angegeben wurde. Die Länge kann ein beliebiger Wert zwischen 0 und 255 sein. Wenn Sie CHAR-Werte speichern, füllen Sie diese rechts mit Leerzeichen bis zur angegebenen Länge auf. Wenn ein CHAR-Wert abgerufen wird, werden nachgestellte Leerzeichen entfernt. Während der Speicherung oder des Abrufs wird keine Fallkonvertierung durchgeführt.

Die Werte in VARCHAR-Spalten sind Zeichenfolgen variabler Länge. Die Länge kann als Wert zwischen 0 und 65.535 angegeben werden. (Die maximale effektive Länge von VARCHAR wird durch die maximale Zeilengröße und den verwendeten Zeichensatz bestimmt. Die maximale Gesamtlänge beträgt 65.532 Byte.) Im Vergleich zu CHAR speichert der VARCHAR-Wert nur die erforderliche Anzahl von Zeichen plus ein Byte zum Aufzeichnen der Länge (wenn die deklarierte Länge der Spalte 255 überschreitet, werden zwei Bytes verwendet). VARCHAR-Werte werden ohne Auffüllung gespeichert. Nachfolgende Leerzeichen bleiben erhalten, wenn der Wert gespeichert und abgerufen wird, entsprechend dem Standard-SQL.

char eignet sich zum Speichern des MD5-Hashwerts des Benutzerpassworts, seine Länge ist immer gleich. char ist auch für Werte, die sich häufig ändern, besser als varchar, da Zeilen mit fester Länge weniger anfällig für Fragmentierung sind, und char ist auch für sehr kurze Spalten effizienter als varchar. Die Zeichenfolge char(1) belegt bei einem Einzelbyte-Zeichensatz nur ein Byte, die Zeichenfolge varchar(1) jedoch 2 Bytes, da 1 Byte zum Speichern der Längeninformationen verwendet wird.

Indexdesign-Spezifikationen

Die Abfragegeschwindigkeit von MySQL hängt von einem guten Indexdesign ab, daher sind Indizes für eine hohe Leistung von entscheidender Bedeutung. Angemessene Indizes beschleunigen Abfragen (einschließlich UPDATE- und DELETE-Geschwindigkeiten. MySQL lädt die Seite, die die Zeile enthält, in den Speicher und führt dann UPDATE- oder DELETE-Vorgänge aus), während unangemessene Indizes die Geschwindigkeit verlangsamen. Die MySQL-Indexsuche ähnelt der Pinyin- und Radikalsuche im Xinhua-Wörterbuch. Wenn der Pinyin- und Radikalindex nicht vorhanden ist, kann er nur durch Umblättern durchsucht werden. Wenn MySQL-Abfragen keine Indizes verwenden können, führt MySQL einen vollständigen Tabellenscan durch, der viel E/A verbraucht. Zweck des Index: Deduplizierung, Beschleunigung der Positionierung, Vermeidung von Sortierungen, Überschreiben des Index.

Was ist ein abdeckender Index? In der InnoDB-Speicher-Engine speichert der Sekundärindex (Nicht-Primärschlüsselindex) nicht direkt die Zeilenadresse, sondern den Primärschlüsselwert. Wenn der Benutzer eine Datenspalte abfragen muss, die nicht im Sekundärindex enthalten ist, muss er zuerst den Primärschlüsselwert über den Sekundärindex finden und dann die anderen Datenspalten über den Primärschlüssel abfragen, sodass dies erforderlich ist zweimal abgefragt werden. Das Konzept des Covering-Index besteht darin, dass die Abfrage in einem Index abgeschlossen werden kann und die Effizienz des Covering-Index relativ hoch ist. Die Primärschlüsselabfrage ist ein natürlicher Covering-Index. Durch die sinnvolle Erstellung von Indizes und die sinnvolle Verwendung von Abfrageanweisungen kann die Leistung bei der Verwendung abdeckender Indizes verbessert werden. Beispiel: SELECT email,uid FROM user_email WHERE uid=xx. Wenn uid nicht der Primärschlüssel ist, können Sie den Index bei Bedarf als index(uid,email) hinzufügen, um die Leistung zu verbessern.

Grundlegende Spezifikationen für Indizes

Kontrollieren Sie die Anzahl der Indizes. Die Anzahl der Indizes in einer einzelnen Tabelle darf 5 nicht überschreiten, und die Anzahl der Felder in einem einzelnen Index darf 5 nicht überschreiten.

Datendichte und -verteilung umfassend auswerten
• Berücksichtigen Sie das Abfrage- und Aktualisierungsverhältnis
• 
  
Warum kann eine Tabelle nicht zu viele Indizes enthalten?

Der Sekundärindex von InnoDB verwendet b+tree zur Speicherung, daher muss b+tree während UPDATE, DELETE und INSERT angepasst werden. Zu viele Indizes verlangsamen die Aktualisierungsgeschwindigkeit.

Verwenden Sie den Präfixindex für Zeichenfolgen. Die Länge des Präfixindex sollte 8 Zeichen nicht überschreiten. Bei Bedarf können Sie Pseudospalten hinzufügen und Indizes erstellen.

Indizieren Sie kein Blob/Text und andere Felder, indizieren Sie keine großen Felder, da der Index dadurch zu viel Speicherplatz beansprucht.

Was ist ein Präfixindex?

Um es ganz klar auszudrücken: Der Präfixindex dient dazu, die ersten paar Zeichen des Textes zu indizieren (insbesondere wie viele Zeichen beim Erstellen des Index angegeben werden), sodass der erstellte Index kleiner ist und die Abfrage schneller erfolgt. Der Präfixindex kann die Größe von Indexdateien effektiv reduzieren und die Indizierungsgeschwindigkeit verbessern. Aber Präfixindizes haben auch ihre Nachteile: MySQL kann Präfixindizes nicht in ORDER BY oder GROUP BY verwenden, noch können sie als abdeckende Indizes verwendet werden.

Syntax zum Einrichten eines Präfixindex: ALTER TABLE Tabellenname ADD KEY(Spaltenname(Präfixlänge));

Primärschlüsselrichtlinien

Die Tabelle muss einen Primärschlüssel haben

Verwenden Sie keine häufig aktualisierten Spalten
• Versuchen Sie es nicht So wählen Sie Zeichenfolgenspalten aus:
Verwenden Sie keinen UUID MD5 HASH Indizes
• UPDATE-, DELETE-Anweisungen WHERE-Bedingungsspalten
• ORDER BY-, GROUP BY-, DISTINCT-Felder
• Mehrtabellen-JOIN-Felder
  

Platzieren Sie die Felder mit der größten Differenzierung an der Vorderseite

• Wählen Sie die Felder aus B. einzelne Nummern, Benutzer-IDs usw., Typ, Status und andere Filtereigenschaften werden im Allgemeinen nicht empfohlen. Der Index basiert auf dem Prinzip des linken Präfixes Wenn ein gemeinsamer Index (a, b, c) erstellt wird, enthält die Abfragebedingung nur (a) oder (a, b) oder (a, b, c). Der Index kann nur verwendet werden, wenn (a, c) vorhanden ist Als Bedingung kann nur der Spaltenindex a verwendet werden. Daher muss zu diesem Zeitpunkt sichergestellt werden, dass die Rückgabespalte von a nicht zu groß sein darf. Andernfalls ist das Anweisungsdesign unangemessen , (b,c) kann nicht indiziert werden
• Erstellen Sie vernünftigerweise einen gemeinsamen Index (um Redundanz zu vermeiden), (a,b,c) entspricht (a), (a,b), ( a,b,c)
  

Index Tabu

• Erstellen Sie keine Indizes für Spalten mit geringer Kardinalität, wie zum Beispiel „Geschlecht“.
• Führen Sie keine mathematischen Operationen und Funktionsoperationen für Indexspalten aus.
• Indizieren Sie keine häufig verwendeten kleinen Tabellen.
• Versuchen Sie, keine Fremdschlüssel zu verwenden.
• Fremdschlüssel werden zum Schutz der referenziellen Integrität verwendet und können auf geschäftlicher Seite realisiert werden
• Die Vorgänge an der übergeordneten und der untergeordneten Tabelle beeinflussen sich gegenseitig und verringern die Verfügbarkeit.
• INNODB selbst unterliegt Einschränkungen für Online-DDL.
  

Einschränkungen für Indizes in MYSQL

Die Summe der Indexlängen der MYISAM-Speicher-Engine darf 1000 Bytes nicht überschreiten
Für BLOB- und TEXT-Typ-Spalten können nur Präfixindizes erstellt werden
MYSQL unterstützt derzeit keine Funktionsindizes
Bei Verwendung von ungleich (!= oder a8093152e673feb7aba1828c43532094) kann MYSQL den Index nicht verwenden.
Nach dem Filtern von Feldern mithilfe von Funktionsoperationen (z. B. abs (Spalte)) kann MYSQL keine Indizes verwenden.
MYSQL kann den Index nicht verwenden, wenn die Join-Bedingungsfeldtypen in der Join-Anweisung inkonsistent sind.
Wenn die Bedingung bei Verwendung der LIKE-Operation mit einem Platzhalter beginnt (z. B. „%abc…“), kann MYSQL den Index nicht verwenden.
Bei Verwendung einer nicht äquivalenten Abfrage kann MYSQL den Hash-Index nicht verwenden.

Anweisungsdesign-Spezifikationen

Verwenden Sie vorkompilierte Anweisungen

• Übergeben Sie nur Parameter, was effizienter ist als die Übergabe von SQL-Anweisungen
• Einmal analysiert, mehrfache Verwendung
• Reduzieren Sie die Wahrscheinlichkeit einer SQL-Injection
  

A nichtig implizite Konvertierung

führt zu Indexfehlern

Nutzen Sie den Präfixindex vollständig aus

• muss das Präfix ganz links sein
• Es ist nicht möglich, zwei Bereichsbedingungen gleichzeitig zu verwenden
• Abfragen, die nicht % führen , wie etwa „%ab“
  

Verwenden Sie keine negativen Abfragen, wie z. B. „not in/like“

• Der Index kann nicht verwendet werden, was zu einem vollständigen Tabellenscan führt
• Der vollständige Tabellenscan führt zu reduziertem Puffer Poolnutzung
  

Vermeiden Sie die Verwendung gespeicherter Prozeduren und Trigger, Server, UDFs, Ereignisse usw.

• Lassen Sie die Datenbank tun, was sie am besten kann
• Reduzieren Sie die Geschäftskopplung und lassen Sie Raum für Sacle-Out und Sharding.
• Vermeiden Sie Fehler
  

Vermeiden Sie die Verwendung von JOIN für große Tabellen

Was MySQL am besten kann, ist die Primärschlüssel-/Sekundärindexabfrage einer einzelnen Tabelle
JOIN verbraucht mehr Speicher und generiert temporäre Tabellen

Vermeiden Sie mathematische Operationen in der Datenbank

• MySQL ist nicht gut in mathematischen Operationen und logischem Urteilsvermögen.
• Indizes können nicht verwendet werden, um die Anzahl der Interaktionen mit der Datenbank zu reduzieren. INSERT INTO VALUES(),(),()
  
UPDATE … WHERE ID IN( 10,20,50,…)

Paging richtig verwenden

• Begrenzen Sie die Anzahl der angezeigten Seiten durch Paging. Sie können nur klicken auf der vorherigen Seite und der nächsten Seite mit verzögerter Zuordnung
• Wie verwende ich Paging richtig?

Angenommen, es gibt eine Paging-Anweisung ähnlich der folgenden: SELECT * FROM table ORDER BY id LIMIT 10000, 10 Da die Art und Weise, wie LIMIT OFFSET in MySQL verarbeitet wird, darin besteht, alle Daten von OFFSET+LIMIT zu entfernen, dann OFFSET zu entfernen und Geben Sie das LIMIT unten zurück. Daher ist die Abfrageleistung von MySQL sehr gering, wenn der OFFSET-Wert groß ist. Es kann durch die Verwendung von ID >

http://example.com/page.php?last=100 
select * from table where id<100 order by id desc limit 10 
//上一页 
 http://example.com/page.php?first=110 
select * from table where id>110 order by id desc limit 10

Der größte Nachteil dieser Methode besteht darin, dass bei einem Einfüge-/Löschvorgang während des Surfens das Umblättern nicht aktualisiert wird und die Gesamtzahl der Seiten möglicherweise immer noch basierend auf der neuen Anzahl (*) berechnet wird kann irgendwann etwas produzieren. Auf einige Datensätze kann nicht zugegriffen werden. Um dieses Problem zu beheben, können Sie weiterhin die aktuelle Seitenzahl eingeben und angeben, ob es Einfüge-/Löschvorgänge gibt, die sich auf die Gesamtzahl der Datensätze seit dem letzten Seitenwechsel auswirken, und diese zwischenspeichern

select * from table where id >= (select id from table order by id limit #offset#, 1)

Großes SQL ablehnen und aufteilen kleines SQL

Nutzen Sie den QUERY CACHE voll ausMachen Sie die Multi-Core-CPU voll aus

Verwenden Sie in anstelle von oder, der Wert von in sollte 1000 nicht überschreiten

Es ist verboten, order by rand() zu verwenden

Verwenden Sie die EXPLAIN-Diagnose, um die Generierung temporärer Tabellen zu vermeiden. Die EXPLAIN-Anweisung (End-End-Ausführung im MySQL-Client) kann Informationen darüber erhalten, wie MySQL die SELECT-Anweisung ausführt. Durch Ausführen von EXPLAIN für die SELECT-Anweisung können Sie feststellen, ob MySQL bei der Ausführung der SELECT-Anweisung Indizes, vollständige Tabellenscans, temporäre Tabellen, Sortierungen und andere Informationen verwendet. Versuchen Sie zu vermeiden, dass MySQL vollständige Tabellenscans durchführt, temporäre Tabellen verwendet, Sortierungen usw. durchführt. Einzelheiten finden Sie in der offiziellen Dokumentation.

Verwenden Sie Union All statt Union.
• Was ist der Unterschied zwischen Union All und Union?
• Die Schlüsselwörter „union“ und „union all“ führen beide zwei Ergebnismengen zu einer zusammen, unterscheiden sich jedoch in Bezug auf Verwendung und Effizienz.
• Union filtert doppelte Datensätze nach der Tabellenverknüpfung heraus, sortiert also nach der Tabellenverknüpfung die generierte Ergebnismenge, löscht doppelte Datensätze und gibt dann die Ergebnisse zurück. Beispiel:

• select * from test_union1 
  union select * from test_union2

Dieses SQL entnimmt beim Ausführen zunächst die Ergebnisse der beiden Tabellen, verwendet dann den Sortierraum zum Sortieren und Löschen doppelter Datensätze und gibt schließlich die Ergebnismenge zurück. Wenn die Tabellendaten groß sind, kann dies dazu führen Festplatte, die sortiert werden soll.
• Und Union All kombiniert einfach die beiden Ergebnisse und gibt sie zurück. Wenn in den beiden zurückgegebenen Ergebnismengen doppelte Daten vorhanden sind, enthält die zurückgegebene Ergebnismenge auf diese Weise doppelte Daten.

• 从效率上说，union all要比union快很多，所以，如果可以确认合并的两个结果集中不包含重复的数据的话，那么就使用union all，如下：

  select * from test_union1 union all select * from test_union2

  •  程序应有捕获SQL异常的处理机制
  • 禁止单条SQL语句同时更新多个表
  • 不使用select * ，SELECT语句只获取需要的字段
  • 消耗CPU和IO、消耗网络带宽
  • 无法使用覆盖索引
  • 减少表结构变更带来的影响
  • 因为大，select/join 可能生成临时表
  • UPDATE、DELETE语句不使用LIMIT
  • INSERT语句必须显式的指明字段名称，不使用INSERT INTO table()
  • INSERT语句使用batch提交（INSERT INTO table VALUES(),(),()……），values的个数不超过500
  • 统计表中记录数时使用COUNT(*)，而不是COUNT(primary_key)和COUNT(1) 备注：仅针对Myisam
  • 数据更新建议使用二级索引先查询出主键，再根据主键进行数据更新
  • 禁止使用跨库查询
  • 禁止使用子查询，建议将子查询转换成关联查询
  • 针对varchar类型字段的程序处理，请验证用户输入，不要超出其预设的长度；
    

  分表规范

  单表一到两年内数据量超过500w或数据容量超过10G考虑分表，需提前考虑历史数据迁移或应用自行删除历史数据，采用等量均衡分表或根据业务规则分表均可。要分表的数据表必须与DBA商量分表策略

  • 用HASH进行散表，表名后缀使用十进制数，下标从0开始
  • 按日期时间分表需符合YYYY[MM][dd][HH]格式
  • 采用合适的分库分表策略。例如千库十表、十库百表等
  • 禁止使用分区表，分区表对分区键有严格要，分区表在表变大后执行DDL、SHARDING、单表恢复等都变得更加困难。
  • 拆分大字段和访问频率低的字段，分离冷热数据
    

  行为规范

  • 批量导入、导出数据必须提前通知DBA协助观察
  • 禁止在线上从库执行后台管理和统计类查询
  • 禁止有super权限的应用程序账号存在
  • 产品出现非数据库导致的故障时及时通知DBA协助排查
  • 推广活动或上线新功能必须提前通知DBA进行流量评估
  • 数据库数据丢失，及时联系DBA进行恢复
  • 对单表的多次alter操作必须合并为一次操作
  • 不在MySQL数据库中存放业务逻辑
  • 重大项目的数据库方案选型和设计必须提前通知DBA参与
  • 对特别重要的库表，提前与DBA沟通确定维护和备份优先级
  • 不在业务高峰期批量更新、查询数据库其他规范
  • 提交线上建表改表需求，必须详细注明所有相关SQL语句
    

  其他规范

  日志类数据不建议存储在MySQL上，优先考虑Hbase或OceanBase，如需要存储请找DBA评估使用压缩表存储。

  相关图文教程：mysql数据库图文教程

Das obige ist der detaillierte Inhalt vonDie umfassendste Weitergabe von MySQL-Nutzungsspezifikationen in der Geschichte. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!