Zusammenfassung des MySQL-Datenbankdesigns

Regel 1: Im Allgemeinen können Sie die MyISAM-Speicher-Engine wählen. Wenn Sie Transaktionsunterstützung benötigen, müssen Sie die InnoDB-Speicher-Engine verwenden.

Hinweis: Der B-Tree-Index der MyISAM-Speicher-Engine weist eine große Einschränkung auf: Die Summe der Längen aller an einem Index beteiligten Felder darf 1000 Bytes nicht überschreiten. Darüber hinaus sind MyISAM-Daten und -Indizes getrennt, während der Datenspeicher von InnoDB nach Cluster-Index geordnet ist und der Primärschlüssel der Standard-Cluster-Index ist. Daher ist die Abfrageleistung von MyISAM im Allgemeinen höher als die von InnoDB, aber die Abfrageleistung von InnoDB basiert auf dem Primärschlüssel Schlüssel ist sehr hoch.

Regel 2: Benennungsregeln.

1. Die Datenbank- und Tabellennamen sollten möglichst konsistent mit dem Namen des bedienten Geschäftsmoduls sein

2. Die erstklassige Tischbedienung Das gleiche Submodul sollte so konsistent wie möglich sein. Verwenden Sie den Submodulnamen (oder einen Teil des Wortes) als Präfix oder Suffix.

3. Der Tabellenname sollte versuchen, das entsprechende Wort einzuschließen die gespeicherten Daten

4. Feld Der Name sollte auch versuchen, mit den tatsächlichen Daten übereinzustimmen

5. Der gemeinsame Indexname sollte versuchen, alle einzuschließen Indexschlüsselfeldnamen oder -abkürzungen, und die Reihenfolge jedes Feldnamens im Indexnamen sollte mit der Indexreihenfolge im Index konsistent sein. Versuchen Sie, ein Präfix oder Suffix ähnlich wie idx einzufügen, um anzuzeigen, dass das Objekt Typ ist ein Index.

6. Andere Objekte wie Einschränkungen sollten möglichst auch die Namen der Tabellen oder anderer Objekte enthalten, zu denen sie gehören, um ihre jeweiligen Beziehungen anzuzeigen

Regeln 3: Definition des Datenbankfeldtyps

1. Für Felder, die häufig Berechnungen und Sortierungen erfordern, die CPU verbrauchen, sollten Sie versuchen, schnellere Felder auszuwählen, z Verwenden Sie TIMESTAMP(4-Zeichen-Abschnitt, Mindestwert 1970-01-01 00:00:00) anstelle von Datetime (8 Bytes, Mindestwert 1001-01-01 00:00:00), ersetzen Sie Gleitkomma und Zeichen Typen mit ganzen Zahlen

2. Verwenden Sie varchar für Felder mit variabler Länge, verwenden Sie nicht char

3. Für binäre Multimediadaten, Pipeline-Daten ( B. Protokolle), extrem groß Platzieren Sie keine Textdaten in Datenbankfeldern

Regel 4: Die Tabelle, die vom Geschäftslogik-Ausführungsprozess gelesen werden muss, muss vorhanden sein ein Anfangswert. Vermeiden Sie das geschäftliche Auslesen negativer oder unendlicher Werte, die zu Programmfehlern führen.

Regel 5: Es ist nicht erforderlich, sich an die Paradigmentheorie zu halten, moderate Redundanz, damit Query Join minimieren kann

Regel 6: Große Felder, auf die seltener zugegriffen wird, werden aus der Datentabelle abgespalten. Einige große Felder beanspruchen viel Platz und werden viel seltener aufgerufen als andere Felder. Durch die Aufteilung der Felder ist es in diesem Fall nicht erforderlich, die großen Felder bei häufigen Abfragen zu lesen, was zu einer Verschwendung von E/A-Ressourcen führt.

Regel 7: Bei großen Tabellen kann eine horizontale Aufteilung in Betracht gezogen werden. Große Tabellen wirken sich auf die Abfrageeffizienz aus. Es gibt viele Aufteilungsmethoden basierend auf Geschäftsmerkmalen. Beispielsweise können Daten, die mit der Zeit zunehmen, nach Zeit aufgeteilt werden. Nach ID geteilte Daten können entsprechend der ID in % der Anzahl der Datenbanken aufgeteilt werden.

Regel 8: Die vom Unternehmen benötigten relevanten Indizes werden anhand der Where-Bedingung der SQL-Anweisung bestimmt, die gemäß dem tatsächlichen Design erstellt wurde. Erstellen Sie keine Indizes, die vom Unternehmen nicht benötigt werden Geschäft. Gemeinsame Indizes sind nicht zulässig (oder Primärschlüssel) enthalten mehr als ein Feld. Insbesondere wird das Feld überhaupt nicht in der bedingten Anweisung angezeigt.

Regel 9: Um ein oder mehrere Felder eines Datensatzes eindeutig zu bestimmen, muss ein Primärschlüssel oder ein eindeutiger Index erstellt werden Verbesserung der Abfrageeffizienz

Regel 10: Einige von Unternehmen verwendete Tabellen verfügen über sehr wenige Datensätze oder sogar nur einen Datensatz. Um die Anforderungen von Einschränkungen zu erfüllen, müssen Indizes oder Primärschlüssel erstellt werden.

Regel 11: Für Felder, deren Werte nicht wiederholt werden können und häufig als Abfragebedingungen verwendet werden, sollte ein eindeutiger Index erstellt werden (der Primärschlüssel ist standardmäßig ein eindeutiger Index) und Die Bedingungen für dieses Feld in den Abfragebedingungen sollten an erster Stelle stehen. Es ist nicht erforderlich, einen gemeinsamen Index für dieses Feld zu erstellen.

Regel 12: Für häufig abgefragte Felder, deren Werte nicht eindeutig sind, sollten Sie auch erwägen, einen normalen Index einzurichten. Setzen Sie die Feldbedingung an die erste Position in der Abfrageanweisung und verarbeiten Sie sie der gemeinsame Index. Die gleiche Methode.

Regel 13: Wenn ein Unternehmen über einen nicht eindeutigen Index auf Daten zugreift, muss es die über den Indexwert zurückgegebene Datensatzdichte berücksichtigen. Grundsätzlich kann die maximal mögliche Dichte nicht höher sein als 0,2. Wenn der Grad zu groß ist, ist es nicht geeignet, einen Index zu erstellen.

Wenn die über diesen Index abgerufene Datenmenge mehr als 20 % aller Daten in der Tabelle ausmacht, müssen gleichzeitig die Kosten für die Erstellung des Index berücksichtigt werden, da das Index-Scannen zufällige I generiert /O, Die resultierende Effizienz ist viel geringer als die sequentielle E/A beim sequentiellen Scan der vollständigen Tabelle. Das Datenbanksystem darf diesen Index bei der Optimierung der Abfrage nicht verwenden.

Regel 14: Datenbanken, die gemeinsame Indizes (oder gemeinsame Primärschlüssel) erfordern, sollten auf die Reihenfolge der Indizes achten. Die Übereinstimmungsbedingungen in der SQL-Anweisung müssen auch mit der Reihenfolge des Index übereinstimmen.

Hinweis: Auch eine falsche Indizierung kann schwerwiegende Folgen haben.

Regel 15: Mehrere Felder in der Tabelle werden als Abfragebedingungen verwendet, enthalten keine anderen Indizes und die gemeinsamen Werte der Felder werden nicht wiederholt. Ein eindeutiger gemeinsamer Index kann aufgebaut werden Angenommen, der Index ist (a1, a2,...an), dann kann die Abfragebedingung (a1 op val1,a2 op val2,...am op valm)m<=n den Index verwenden. Die Position des Felds in der Abfragebedingung stimmt mit der Position von überein das Feld im Index.

Regel 16: Grundsätze für die Erstellung gemeinsamer Indizes (im Folgenden wird davon ausgegangen, dass ein gemeinsamer Index (a, b, c) für die Felder a, b, c der Datenbanktabelle erstellt wird)

1. Die Felder im gemeinsamen Index sollten versuchen, die Reihenfolge der gefilterten Daten von den meisten bis zu den wenigsten zu erfüllen, d. h. das Feld mit der größten Differenz sollte das erste Feld sein

2. Die Indexerstellung sollte so weit wie möglich mit der Bedingungsreihenfolge der SQL-Anweisung übereinstimmen, sodass die SQL-Anweisung so weit wie möglich auf dem gesamten Index basieren sollte, und versuchen Sie, die Verwendung zu vermeiden ein Teil des Index (insbesondere wenn die erste Bedingung nicht mit dem ersten Feld des Index übereinstimmt) als Abfragebedingung

3. Where a=1,where a>=12 and a<15,where a=1 and b<5 ,where a=1 and b=7 and c>=40为条件可以用到此联合索引；而这些语句where b=10,where c=221,where b>=12 and c=2则无法用到这个联合索引。

4. Wenn alle abzufragenden Datenbankfelder im Index enthalten sind, kann die Datenbank den Index direkt abfragen, um die Abfrageinformationen zu erhalten, ohne die gesamte Tabelle zu scannen (dies ist der sogenannte Nur-Schlüssel). Verbessern Sie die Abfrageeffizienz erheblich.
   Der Index kann beim Abfragen von a, ab, abc in Verbindung mit anderen Tabellenfeldern verwendet werden

5. Wenn a, ab, abc anstelle von b, c, bc in der richtigen Reihenfolge sind, ac. Indizes können beim Ausführen von „Ordnen nach“ oder „Gruppe“ verwendet werden.

6. In den folgenden Situationen kann das Scannen und Sortieren von Tabellen effektiver sein als die Verwendung gemeinsamer Indizes.
   Die Tabelle wurde organisiert nach dem Index
   b. Ein großer Teil aller Daten in der abgefragten Datenstation.

Regel 17: Wenn wichtige Unternehmen auf Datentabellen zugreifen. Wenn jedoch nicht über Indizes auf Daten zugegriffen werden kann, sollten Sie sicherstellen, dass die Anzahl der Datensätze, auf die nacheinander zugegriffen wird, begrenzt ist und im Prinzip nicht mehr als 10 betragen sollte.

Regel 18: Angemessen konstruieren Abfrageanweisungen

1. Tests zufolge ist es am effizientesten, 1.000 Elemente gleichzeitig in einen Stapel einzufügen. Wenn mehr als 1.000 Elemente vorhanden sind, muss dies der Fall sein Wenn die gleiche Einfügung mehrmals durchgeführt wird, sollte sie zusammengeführt und gestapelt werden. Beachten Sie, dass die Länge der Abfrageanweisung kleiner sein sollte als der mysqld-Parameter max_allowed_packet

2. Die Leistungsreihenfolge der verschiedenen logischen Operatoren in den Abfragebedingungen ist und, oder, in, also sollten Sie es tun Versuchen Sie zu vermeiden, sie in den Abfragebedingungen zu verwenden. Wenn Sie in

3. in einem großen Satz verwenden, verwenden Sie immer einen kleinen Ergebnissatz, um einen großen Datensatz zu steuern, da dies in MySQL nur der Fall ist Eine Join-Methode, Nested Join, bedeutet, dass der Join von MySQL durch eine verschachtelte Schleife erreicht wird. Das Prinzip kleiner Ergebnismengen, die große Datensatzmengen antreiben, wird verwendet, um die Anzahl der verschachtelten Schleifen zu reduzieren, um die Gesamtmenge an E/A und die Anzahl der CPU-Operationen zu reduzieren.

4. Versuchen Sie, das Innere zu optimieren Schleife von Nested Join.

5. Nur ​​die erforderlichen Spalten verwenden, versuchen Sie, select * nicht zu verwenden

6. Verwenden Sie nur die effektivsten Filterfelder, es gibt nur wenige Filterbedingungen die where-Klausel Für das Beste

7. Vermeiden Sie komplexe Verknüpfungen und Unterabfragen

   Mysql ist nicht sehr gut in der Parallelität Der starke Rückgang hängt hauptsächlich mit der Konkurrenzsperrensteuerung der internen Ressourcen von MySQL zusammen. MyIsam verwendet Tabellensperren und InnoDB verwendet Zeilensperren.

Regel 19: Optimierung des Anwendungssystems

1. Verwenden Sie den Cache vernünftig, für Teile, die sich weniger aktiv ändern Daten werden über den Anwendungsschicht-Cache im Speicher zwischengespeichert, was die Leistung um Größenordnungen verbessert.

2. Führen Sie dieselbe Abfrage wiederholt zusammen, um die Anzahl der E/As zu reduzieren.

Prinzip der minimalen Transaktionsrelevanz

Das obige ist der detaillierte Inhalt vonZusammenfassung des MySQL-Datenbankdesigns. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!