Heim  >  Artikel  >  Datenbank  >  Entwicklung von Hochleistungs-MySql (1): Optimierung von Datentypen_Teil 1

Entwicklung von Hochleistungs-MySql (1): Optimierung von Datentypen_Teil 1

黄舟
黄舟Original
2017-02-09 15:00:46981Durchsuche

Der Prozess der Optimierung der Datenbankleistung erfordert viel Wissen, einschließlich der Frage, ob die Feldattributeinstellungen angemessen sind, ob die Indexerstellung angemessen ist, ob die Tabellenstruktur angemessen ist und ob die Datenbank-/Betriebssystemeinstellungen korrekt sind. .. Jedes Thema kann ein Feld sein.

Meiner Meinung nach ist die Optimierung von Feldern eine der Schlüsseltechnologien zur Verbesserung der Datenbankleistung, relativ schwierig und hat einen sehr großen Einfluss auf die Leistung. Da MySQL viele Datentypen unterstützt und jeder Typ seine eigenen einzigartigen Eigenschaften hat, wählt man bei der Auswahl eines bestimmten Datentyps manchmal nach Belieben einen verwendbaren Typ aus, ohne dies zu berücksichtigen Ob der Typ optimal ist. Bevor wir die spezifischen Typen beschreiben, werfen wir zunächst einen Blick auf einige Hauptprinzipien für die Auswahl von Datentypen:

a) Versuchen Sie, Typen auszuwählen, die weniger Platz beanspruchen
, da sich kleine Typen entweder auf der Festplatte oder im Speicher befinden Der belegte Platz ist gering und der von der temporären Tabelle zum Abfragen oder Sortieren benötigte Platz ist relativ gering. Wenn die Datenmenge relativ klein ist, spüren Sie es möglicherweise nicht, aber wenn die Datenmenge relativ groß ist, wird die Bedeutung dieses Prinzips möglicherweise deutlich.

Zum Beispiel gibt es eine Tabelle „Produktinformationen“ mit 20 Millionen Datensätzen. Diese Tabelle verfügt im Allgemeinen über ein Feld „verbleibende Produktmenge“ (COUNT). Bereich: 0-65535) reicht aus, um dieses Feld auszudrücken. Wenn Sie jedoch BIGINT (len: 64 Bereich: 0-18446744073709551615) verwenden, um es während des Entwurfsprozesses auszudrücken, wird dieses Feld zwar ordnungsgemäß ausgeführt, obwohl das Programm möglicherweise ordnungsgemäß ausgeführt wird Es fügt etwa 95 MB hinzu Zusätzlicher Speicherplatz auf der Festplatte (64-16)/8*20.000.000 Bytes. Darüber hinaus erhöht allein dieses Feld Ihren Speicherverbrauch um 95 MB. Basierend auf den Auswirkungen des oben genannten Verhaltens Die Datenbank wird unweigerlich beeinträchtigt

Die Prämisse, sie so klein wie möglich zu halten, besteht darin, sicherzustellen, dass der von Ihnen gewählte Typ den Anforderungen der zukünftigen Geschäftsentwicklung gerecht wird, da die Tabellenstruktur bei Bedarf aktualisiert werden muss Die Datenmenge ist relativ groß. Es ist eine sehr langsame und mühsame Sache.

b) Versuchen Sie, einfache/geeignete Typen auszuwählen

Beim Auswählen und Sortieren von Tabellen verbrauchen einfache Typen oft weniger CPU-Taktzyklen. Beispielsweise ist für einen MySQL-Server der Vergleich von Werten vom Typ Ganzzahl oft einfacher und schneller als der Vergleich von Werten vom Typ Zeichenfolge. Wenn Sie also eine bestimmte Tabelle sortieren müssen, sollten Sie versuchen, den Ganzzahltyp als Grundlage für die Sortierung auszuwählen

c) Versuchen Sie, das Feld auf NOTNULL zu setzen.
Wenn Sie ein Feld nicht explizit als NULL angeben, wird dieses Feld vom Datenbanksystem als NULLABLE betrachtet. Das Standardverhalten verursacht die folgenden drei Probleme
(1) Die eigene Abfrageoptimierungsfunktion des MySQL-Servers wird beeinträchtigt
(2) MySQL benötigt zusätzlichen Speicherplatz und Verarbeitung für Nullwertfelder
(3 ) Wenn ein Nullwert Teil ist des Index wird auch der Indexeffekt beeinflusst

Da dieses Prinzip keinen großen Einfluss auf die Verbesserung der Datenbankleistung hat, gibt es ein NULLABLE-Feld für das vorhandene DB-Schema. Oder wenn der Index NULLABLE ist Es besteht keine Notwendigkeit, es speziell zu ändern. Bei neu gestalteten DBs oder Indizes muss dieses Prinzip jedoch so weit wie möglich eingehalten werden.

Nachdem die Prinzipien der Datentypauswahl vorgestellt wurden, werden im Folgenden die gängigen Datentypen in MySQL vorgestellt und worauf bei der Leistungsoptimierung geachtet werden muss.

· Integer
Zu den Mitgliedern der Integer-Familie von MySQL gehören hauptsächlich TINYINT(8bit), SMALLINT(16bit), MEDIUMINT(24bit), INT(32bit) oder BIGINT(64bit).

Für vorzeichenbehaftete Ganzzahlen beträgt der Speicherbereich dieser Typen (-2(n-1), 2(n-1)-1), und für vorzeichenlose Zahlen beträgt der Ausdrucksbereich (0, 2n- 1) Für die Datenbank belegen vorzeichenbehaftete und vorzeichenlose Zahlen denselben Speicherplatz. Daher können Sie bei der Auswahl des Typs nur den Bereich der Zahl berücksichtigen, ohne zu berücksichtigen, ob sie vorzeichenbehaftet oder vorzeichenlos ist

Mysql erlaubt Sie geben die Breite an, wenn Sie einen Ganzzahltyp definieren, z. B. INT(10). Es gibt einen Unterschied in der Ausgabe von INT(10) für Client/CMD Line, aber aus der Sicht von MySQL Server gibt es keinen Unterschied zwischen INT(10) und INT(32) hinsichtlich des tatsächlichen Speicherplatzes/Rechenverbrauchs/ Nummernkreis.

· Decimal
In MySQL umfassen die Datentypen der Dezimalfamilie hauptsächlich FLOAT (4 Bytes) und DOUBLE (8 Bytes). Aus dem Speicherplatz dieser beiden Typen ist ersichtlich, dass der Zugriff von Dezimalzahlen sind teurer als Ganzzahlen, daher sollten Sie versuchen, die Verwendung des Dezimaltyps zu vermeiden.

Beim Erstellen eines Dezimaltypfelds können Sie FLOAT(10,3) verwenden, um anzugeben Genauigkeit der Dezimalstelle, >= Die maximale Genauigkeit in der MySQL 5.0-Version unterstützt 65 Dezimalstellen.

Da die Datenbank Binary Array String zum Speichern der Zahlen nach dem Dezimalpunkt verwendet, gilt: Je höher die erforderliche Genauigkeit, desto höher kann der Speicherplatz/CPU-Takt für die Berechnung sein.

Obwohl die Verwendung von Dezimalzahlen möglicherweise mehr Speicherplatz und CPU-Ressourcen verbraucht und bei früheren MySQL-Versionen die Genauigkeit verloren geht, ist dies in vielen Fällen erforderlich Speicherung von Beträgen. In vielen Fällen werden Dezimalzahlen häufig in Ganzzahlen erweitert und in der Datenbank gespeichert, um den Speicheraufwand zu reduzieren und die Genauigkeit zu gewährleisten. Die Dezimalzahlen werden dann in der Anwendung konvertiert und berechnet. Bleibt der Kontostand eines Benutzers beispielsweise bei 999,35 Yuan? Der in den Daten gespeicherte Betrag beträgt 99935 Punkte. Nachdem das Verarbeitungsprogramm der Bank 99935 Punkte erhalten hat, wandelt es diese zunächst in 999,35 Yuan um und führt dann die entsprechende Verarbeitung durch

· Zeichenkette

String ist unabhängig von der Sprache ein relativ wichtiger und komplexer Typ.
In MYSQL gibt es zwei Haupt-String-Typen: VARCHAR und CHAR in Festplatte und Speicher wird von der Speicher-Engine bestimmt, und verschiedene Speicher-Engines können unterschiedliche Speichermethoden haben. Im Allgemeinen sind bei einer Speicher-Engine auch die Speichermethoden auf Festplatte und Speicher unterschiedlich. Wenn Daten zwischen Festplatte und Speicher übertragen werden, ist die Speicher-Engine für die Konvertierung der Daten verantwortlich
VARCHAR
Zunächst einmal Es muss darauf hingewiesen werden, dass MySQL zum Speichern von VARCHAR eine variable Länge verwendet. Diese Methode verwendet die Speicherstrategie „So viel wie nötig verwenden“, was eine relativ platzsparende Speicherlösung darstellt als Standardtyp ohne besondere Anforderungen

Der Grund, warum VARCHAR eine feste Länge erreichen kann, liegt darin, dass an jeden VARCHAR-Wert ein Längenindikator von 1-2 Byte angehängt wird, wenn er beispielsweise „ „Ich liebe Java“ ist der zugrunde liegende Speicherinhalt „11I Love Java“, wobei 11 (1 Byte) die Länge darstellt. Wenn die Länge des zu speichernden Inhalts 1000 beträgt, benötigt der Längenindikator zwei Bytes. Da der Maximalwert von 2 Bytes 216 beträgt, treten unvorhersehbare Ausnahmen auf. In diesem Fall muss CLOB zum Speichern solcher extrem langen Zeichenfolgen verwendet werden.

In verschiedenen Versionen von MYSQL ist auch die Verarbeitung von nachgestellten Leerzeichen für VARCHAR-Felder unterschiedlich
Version>=5.0 Nachgestellte Leerzeichen beibehalten
Version
zu MYSQL 5.6 ist ein Beispiel:

Entwicklung von Hochleistungs-MySql (1): Optimierung von Datentypen_Teil 1


Der Speicherplatzaufwand bei der Verwendung von VARCHAR(5) und VARCHAR(200) zum Speichern von „Hallo“ beträgt Dasselbe. Gibt es also Vorteile bei der Verwendung kürzerer Spalten?

Es stellt sich als großer Vorteil heraus. Größere Spalten verbrauchen mehr Speicher, da MySQL normalerweise Speicherblöcke mit fester Größe für die Speicherung interner Werte zuweist. Dies ist besonders schlimm, wenn temporäre In-Memory-Tabellen zum Sortieren oder für Vorgänge verwendet werden. Ebenso schlimm ist es beim Sortieren mithilfe temporärer Festplattentabellen.

Die beste Strategie besteht also darin, nur den Platz zuzuweisen, den Sie wirklich benötigen.

CHAR
Der größte Unterschied zwischen CHAR-Typ und VARCHAR-Typ besteht darin, dass er eine feste Länge hat. Gleichzeitig weist es im Vergleich zu VARCHAR hauptsächlich die folgenden Merkmale auf
1) In allen MYSQL-Versionen werden die nachgestellten Leerzeichen abgeschnitten

Entwicklung von Hochleistungs-MySql (1): Optimierung von Datentypen_Teil 1

2) Für einige kurz und Felder mit grundsätzlich gleicher Länge sind eine gute Wahl, z. B. MD5, ID-Nummer
3) Für Felder, die häufig geändert werden müssen, ist der CHAR-Typ effizienter
4) Für einige ultrakurze Felder Feldern ist es zudem sehr platzsparend. Wenn Sie beispielsweise „Y“ oder „N“ speichern, erfordert die Verwendung von CHAR nur ein Byte, während die Verwendung von VARCHAR zwei Bytes erfordert (1 Byte Länge + 1 Byte-Wert).

Für CHAR mit fester Länge, Mysql Der Server weist ausreichend Speicherplatz zu, indem Leerzeichen entsprechend der definierten Länge aufgefüllt werden. Zu beachten ist, dass die Vorgänge „Leerzeichen füllen“ und „nachgestellte Leerzeichen entfernen“ für VARCHAR/CHAR vom MySQL-Server implementiert werden und nichts mit der Speicher-Engine zu tun haben

Das Obige ist die Evolutionstheorie von Hochleistungs-MySql (1):Datentypoptimierung_Inhalte auf, für weitere verwandte Inhalte achten Sie bitte auf die chinesische PHP-Website (www.php.cn)!


Stellungnahme:
Der Inhalt dieses Artikels wird freiwillig von Internetnutzern beigesteuert und das Urheberrecht liegt beim ursprünglichen Autor. Diese Website übernimmt keine entsprechende rechtliche Verantwortung. Wenn Sie Inhalte finden, bei denen der Verdacht eines Plagiats oder einer Rechtsverletzung besteht, wenden Sie sich bitte an admin@php.cn