Warum sollte die Anzahl der Zeilen in einer einzelnen MySQL-Tabelle 5 Millionen nicht überschreiten?

Lassen Sie uns heute ein interessantes Thema besprechen: Wie viele Daten benötigt eine einzelne MySQL-Tabelle, bevor Sie über eine Aufteilung der Datenbank und der Tabellen nachdenken müssen? Einige sagen 20 Millionen Zeilen, andere sagen 5 Millionen Zeilen. Also, welcher Wert halten Sie für angemessen?

In chinesischen Internet-Technologiekreisen gab es einst ein weit verbreitetes Sprichwort: Wenn die Datenmenge in einer einzelnen MySQL-Tabelle 20 Millionen Zeilen überschreitet, wird die Leistung erheblich reduziert. Tatsächlich soll dieses Gerücht von Baidu stammen. Die konkrete Situation ist ungefähr so. Als der DBA die MySQL-Leistung testete, stellte er fest, dass die Leistung von SQL-Operationen stark abfiel, wenn das Volumen einer einzelnen Tabelle 20 Millionen Zeilen erreichte. Daher ergab sich daraus die Schlussfolgerung. Dann hieß es, die Ingenieure von Baidu seien zu anderen Unternehmen in der Branche gewechselt und hätten diese Informationen mitgebracht, sodass sich dieses Gerücht in der Branche verbreitete.

Später empfahl Alibabas „Java Development Manual“, die Datenbank und die Tabellen nur dann aufzuteilen, wenn die Anzahl der Zeilen in einer einzelnen Tabelle 5 Millionen überschritt oder die Kapazität einer einzelnen Tabelle 2 GB überschritt. Die goldene Regel von Alibaba unterstützt dies. Daher verwenden viele Leute sie als Standard für die Tabellenpartitionierung beim Entwurf von Big Data-Speichern.

Also, welcher Wert halten Sie für angemessen? Warum nicht 3 Millionen Zeilen oder 8 Millionen Zeilen, sondern 5 Millionen Zeilen? Vielleicht würden Sie sagen, dass dies Alis bester tatsächlicher Kampfwert sein könnte? Die Frage ist also, wie dieser Wert bewertet wird. Warten Sie einen Moment, denken Sie bitte einen Moment darüber nach.

Tatsächlich hat dieser Wert nichts mit der tatsächlichen Anzahl der Datensätze zu tun, sondern hängt mit der Konfiguration von MySQL und der Hardware des Computers zusammen. Denn um die Leistung zu verbessern, lädt MySQL den Index der Tabelle in den Speicher. Wenn die InnoDB-Puffergröße ausreichend ist, können alle Daten in den Speicher geladen werden und es treten keine Probleme mit der Abfrage auf. Wenn jedoch eine Datenbank mit einer einzelnen Tabelle eine bestimmte Obergrenze erreicht, kann der Speicher ihren Index nicht speichern, sodass nachfolgende SQL-Abfragen Festplatten-E/A generieren und die Leistung dadurch beeinträchtigt wird. Dies hängt natürlich auch mit dem Entwurf der spezifischen Tabellenstruktur zusammen, und das letzte Problem ist die Speicherbegrenzung. Hier kann eine Erhöhung der Hardwarekonfiguration unmittelbare Leistungsverbesserungen bringen.

Meine Meinung zum Thema Datenbank- und Tabellen-Sharding ist, dass es mit den tatsächlichen Anforderungen kombiniert werden muss und nicht überdimensioniert werden sollte. Datenbank- und Tabellen-Sharding sollte nicht gleich zu Beginn des Projekts eingeführt werden. Wenn das Geschäft wächst und die Optimierung nicht mehr fortgesetzt werden kann, sollte Datenbank- und Tabellen-Sharding in Betracht gezogen werden, um die Systemleistung zu verbessern. In diesem Zusammenhang fügt Alibabas „Java Development Manual“ hinzu: Wenn Sie davon ausgehen, dass die Datenmenge dieses Niveau in drei Jahren nicht erreichen wird, teilen Sie die Datenbank oder Tabelle beim Erstellen der Tabelle bitte nicht auf. Kommen wir also zurück zur ursprünglichen Frage: Welchen Wert halten Sie für angemessen? Mein Vorschlag ist, eine umfassende Bewertung basierend auf der Situation Ihrer eigenen Maschine vorzunehmen. Wenn Sie keinen Standard im Sinn haben, verwenden Sie vorübergehend 5 Millionen Zeilen als einheitlichen Standard, was ein relativ kompromissbereiter Wert ist.

Werfen wir einen Blick auf einige Punkte zum Schreiben von SQL, die für alle hilfreich sein werden

Das Schreiben von SQL muss optimiert werden

• Verwenden Sie „Limit“, um die Datensätze in den Abfrageergebnissen einzuschränken
• Vermeiden Sie „select *“ und listen Sie die Felder auf, nach denen Sie suchen müssen.
• Verwenden Sie Verknüpfungen anstelle von Unterabfragen
• Aufteilen großer Delete- oder Insert-Anweisungen
• Sie können das langsame SQL herausfinden, indem Sie das Protokoll für langsame Abfragen aktivieren
• Keine Spaltenoperationen: SELECT id WHERE age + 1 = 10. Jede Operation an der Spalte führt zu einem Tabellenscan, einschließlich Datenbank-Tutorialfunktionen, Berechnungsausdrücke usw. Versuchen Sie beim Abfragen, die Operation rechts neben das Gleichheitszeichen zu verschieben.
• Die SQL-Anweisung sollte so einfach wie möglich sein: Eine SQL-Anweisung kann nur auf einer CPU ausgeführt werden; große Anweisungen sollten in kleine Anweisungen aufgeteilt werden, um die Sperrzeit zu verkürzen; eine große SQL-Anweisung kann die gesamte Datenbank blockieren
• Schreiben Sie OR in IN um: OR hat eine Effizienz von n, während IN eine Effizienz von log(n) hat. Es wird empfohlen, die Anzahl der INs auf 200 zu begrenzen.
• Es sind keine Funktionen oder Trigger erforderlich, um
• Vermeiden Sie Abfragen im %xxx-Stil
• Verwenden Sie JOIN sparsam
• Verwenden Sie zum Vergleich den gleichen Typ, z. B. „123“ und „123“, 123 und 123
• Vermeiden Sie nach Möglichkeit die Verwendung der Operatoren != oder <> in der WHERE-Klausel. Andernfalls gibt die Engine den Index auf und führt einen vollständigen Tabellenscan durch.
• Für aufeinanderfolgende Werte verwenden Sie BETWEEN statt IN: SELECT id FROM t WHERE num BETWEEN 1 AND 5
• Verwenden Sie nicht die gesamte Tabelle für Listendaten. Verwenden Sie LIMIT, um die Daten in Seiten aufzuteilen. Die Anzahl der Seiten sollte nicht zu groß sein.