MySQL verwendet die Partitionsfunktion, um eine horizontale Partitionierungsstrategie zu implementieren

1 Bewertung

Im vorherigen Abschnitt haben wir ausführlich erklärt, wie man eine Datenbank partitioniert, einschließlich vertikaler Aufteilung (Scale Up) und horizontaler Aufteilung (Scale Out). Außerdem haben wir kurz mehrere Strategien für die horizontale Partitionierung zusammengefasst. Lassen Sie uns diese nun noch einmal durchgehen.

2 Fünf Strategien zur horizontalen Partitionierung

2.1 Hash

Diese Strategie besteht darin, den Hash-Schlüssel einer oder mehrerer Spalten der Tabelle zu berechnen und schließlich die Datenbereiche zu partitionieren, die unterschiedlichen Werten des Hash-Codes entsprechen. Beispielsweise können wir eine Strategie zum Partitionieren des Jahres des Datums in der Tabelle erstellen, sodass jedes Jahr in einem Intervall gruppiert wird.

 PARTITION NACH HASH(JAHR(Erstellungszeit))
 PARTITIONEN 10

2.2 Reichweite

Diese Strategie besteht darin, die Daten in verschiedene Bereiche aufzuteilen. Beispielsweise können wir eine Tabelle mit mehreren zehn Millionen Daten nach ID in vier Partitionen aufteilen, wobei jede Partition etwa 5 Millionen Daten enthält und alle Daten über 7,5 Millionen in der vierten Partition abgelegt werden.

PARTITION NACH RANGE(id) (
 PARTITIONP0-WERTE KLEINER ALS (2500001),
 PARTITIONP1-WERTE KLEINER ALS (5000001),
 PARTITIONp2 WERTE KLEINER ALS (7500001),
 PARTITIONp3-WERTE KLEINER ALS MAXIMALER WERT
 )

2.3. Schlüssel

Eine Erweiterung der Hash-Strategie, bei der der Hash-Schlüssel vom MySQL-System generiert wird.

2.4. Liste (vordefinierte Liste)

Diese Strategie ermöglicht es dem System, die Zeilen nach den Werten aufzuteilen, die der definierten Liste entsprechen. Beispielsweise teilen wir den Bereich nach dem Jobcode auf, und die Codes verschiedener Jobtypen entsprechen unterschiedlichen Partitionen, um das Ziel „Teile und herrsche“ zu erreichen.

 PARTITION BY LIST(gwcode) (
 PARTITIONP0-WERTE IN (46,77,89),
 PARTITIONP1-WERTE IN (106,125,177),
 PARTITIONP2-WERTE IN (205,219,289),
 PARTITIONP3-WERTE IN (302,317,458,509,610)
)

Das obige SQL-Skript verwendet die Listenabgleichfunktion LIST, um die Stellennummern der Mitarbeiter in vier Partitionen aufzuteilen. Administrative Stellen mit den Nummern 46, 77 und 89 befinden sich in Partition P0, technische Stellen mit den Nummern 106, 125 und 177 in Partition P1 und so weiter.

2.5. Zusammengesetzt

Der zusammengesetzte Modus ist eigentlich eine Kombination der oben genannten Modi. Sie können beispielsweise eine Hash-Partitionierung auf der Grundlage des Bereichs durchführen.

3 Testbereichsstrategie

3.1 Mastertabelle und Untertabelle erstellen

Wir erstellen eine gemeinsame Benutzertabelle „users“ und erstellen dann eine Partitionstabelle „users_part“, um Benutzer, die in den 1980er Jahren geboren sind, wie folgt nach Jahr zu partitionieren:

3.1.1 Zusammenfassende Tabellenanweisung

mysql> CREATE TABLE-Benutzer
(
 "id" int(10) unsigned NOT NULL,
  "Name" varchar(100) DEFAULT NULL,
  "Geburt" Datum/Uhrzeit
)ENGINE=InnoDB STANDARD-CHARSET=utf8;
Abfrage OK, 0 Zeilen betroffen

3.1.2 Split-Tabellenanweisung

Beachten Sie, dass die letzte Zeile alle nach 1989 geborenen Benutzer der 10. Partition zuweist. Wir simulieren Benutzer, die in den 1980er Jahren geboren wurden, und das tatsächliche Geschäft wird entsprechend der spezifischen Situation aufgeteilt.

 mysql> Tabelle Benutzerteil erstellen
 (
   "id" int(10) unsigned NOT NULL,
    "Name" varchar(100) DEFAULT NULL,
    "Geburt" Datum/Uhrzeit
  ) ENGINE=InnoDB STANDARD-CHARSET=utf8
  PARTITION NACH BEREICH (Jahr(Geburt)) (
  PARTITION p0 WERTE WENIGER ALS (1981),
  PARTITION p1 WERTE WENIGER ALS (1982),
 PARTITION p2 WERTE WENIGER ALS (1983),
 PARTITION p3 WERTE WENIGER ALS (1984),
 PARTITION p4 WERTE WENIGER ALS (1985),
 PARTITION p5 WERTE WENIGER ALS (1986),
PARTITION p6 WERTE WENIGER ALS (1987),
 PARTITION p7 WERTE WENIGER ALS (1988),
 PARTITION p8 WERTE WENIGER ALS (1989),17 PARTITION p9 WERTE WENIGER ALS MAXIMALER WERT
 );
 Abfrage OK, 0 Zeilen betroffen

3.2 Tabellendaten initialisieren

Wir können Funktionen oder gespeicherte Prozeduren verwenden, um Daten stapelweise zu initialisieren und hier 10 Millionen Datenstücke einzufügen.

DROP-VERFAHREN, WENN EXISTIERT init_users_part;

Trennzeichen $ /* Setzt das Anweisungsabschlusszeichen auf $*/
PROZEDUR ERSTELLEN init_users_part()
 beginnen
  DECLARE srt int Standard 0;
  während
    srt < 10000000 /* Eingestellt zum Schreiben von 1000W Daten*/
   Tun
  in `users_part` Werte einfügen (srt, concat('username_',idx1),adddate('1980-01-01',rand() * 3650)); /*Werte innerhalb von 10 Jahren zufällig auswählen*/
 setze srt = srt + 1;
 Ende während;
 Ende $
Trennzeichen ;


rufen Sie init_users_part() auf;

3.3 Daten mit der gesamten Tabelle synchronisieren

mysql> insert into users select * from users_part; //10 Millionen Daten in die unpartitionierte vollständige Tabelle „users“ kopieren. Abfrage OK, 10000000 Zeilen betroffen (51,59 Sek.) 

 Datensätze: 10000000 Duplikate: 0 Warnungen: 0

3.4 Testen Sie die Effizienz der SQL-Ausführung

mysql> select count(*) from users_part where „Geburt“ > „01.01.1986“ und „Geburt“ < „31.12.1986“;
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (0,335 Sek.)
mysql> select count(*) from users where `Geburt` > '1986-01-01' und `Geburt` < '1986-12-31';
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (5,187 Sek.)

Die Ergebnisse sind ziemlich eindeutig. Die Ausführungseffizienz der partitionierten Tabelle ist tatsächlich höher und die Ausführungszeit beträgt weniger als 1/10 der Ausführungszeit der nicht partitionierten Tabelle.

3.5 Verwenden von Explain zur Durchführung von Plananalysen

mysql> erläutern Sie „select count(*) from users_part“, wobei „Geburt“ > „1986-01-01“ und „Geburt“ < „1986-12-31“;
+----+-------------+------------+------------+------+---------------+---------+---------+------+---------+------+----------+----------+-------------+
| ID | Auswahltyp | Tabelle | Partitionen | Typ | mögliche Schlüssel | Schlüssel | Schlüssellänge | Ref. | Zeilen | gefiltert | Extra |
+----+-------------+------------+------------+------+---------------+---------+---------+------+---------+------+----------+----------+-------------+
| 1 | SIMPLE | users_part | p7 | ALL | NULL | NULL | NULL | NULL | 987769| 100,00 | Verwenden von „where“ |
+----+-------------+------------+------------+------+---------------+---------+---------+------+---------+------+----------+----------+-------------+
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

mysql> erläutern Sie „select count(*) from users“, wobei „Geburt“ > „1986-01-01“ und „Geburt“ < „1986-12-31“ ist;
+----+----------+----------+---------+------+---------------+---------+---------+------+---------+---------+---------+----------+-------------+
| ID | Auswahltyp | Tabelle | Partitionen | Typ | mögliche Schlüssel | Schlüssel | Schlüssellänge | Ref. | Zeilen | gefiltert | Extra |
+----+----------+----------+---------+------+---------------+---------+---------+------+---------+---------+---------+----------+-------------+
| 1 | SIMPLE | Benutzer | NULL | ALLE | NULL | NULL | NULL | NULL |10000000 | 100,00 | Verwenden von „where“ |
+----+----------+----------+---------+------+---------------+---------+---------+------+---------+---------+---------+----------+-------------+
1 Zeile im Satz, 1 Warnung (0,00 Sek.)

Hier konzentrieren wir uns auf zwei Schlüsselparameter: Einer davon sind Partitionen. Im users_part ist es p7, was bedeutet, dass die Daten in der siebten Partition abgerufen werden. Die users-Tabelle ist null, was bedeutet, dass es sich um einen Vollbereichsscan ohne Partitionen handelt.

Ein weiterer Parameter sind Zeilen, also die Anzahl der voraussichtlich zu scannenden Zeilen. Bei der Benutzertabelle handelt es sich offensichtlich um einen vollständigen Tabellenscan.

3.6 Verbesserung der Indexierungseffizienz

Da wir das Geburtsfeld zur Partitionierung und für bedingte Abfragen verwenden, versuchen wir, zur Optimierung der Effizienz einen Index für das Geburtsfeld zu erstellen.

mysql> erstelle Index idx_user für Benutzer (Geburt);
Abfrage OK, 0 Zeilen betroffen (1 Min. 7,04 Sek.)
Datensätze: 10000000 Duplikate: 0 Warnungen: 0

mysql> erstelle Index idx_user_part auf users_part(Geburt);
Abfrage OK, 0 Zeilen betroffen (1 Min. 1,05 Sek.)
Datensätze: 10000000 Duplikate: 0 Warnungen: 0

Liste der Datenbankdateigrößen nach der Indexerstellung:

24.05.2008 09:23 8,608 no_part_tab.frm
24.05.2008 09:24 255.999.996 no_part_tab.MYD
24.05.2008 09:24 81.611.776 no_part_tab.MYI
2008-05-24 09:25 0 part_tab#P#p0.MYD
24.05.2008 09:26 1.024 part_tab#P#p0.MYI
2008-05-24 09:26 25,550,656 part_tab#P#p1.MYD
2008-05-24 09:26 8,148,992 part_tab#P#p1.MYI
2008-05-24 09:26 25,620,192 part_tab#P#p10.MYD
2008-05-24 09:26 8,170,496 part_tab#P#p10.MYI
2008-05-24 09:25 0 part_tab#P#p11.MYD
24.05.2008 09:26 1.024 part_tab#P#p11.MYI
2008-05-24 09:26 25,656,512 part_tab#P#p2.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p2.MYI
2008-05-24 09:26 25,586,880 part_tab#P#p3.MYD
2008-05-24 09:26 8,160,256 Teil_Tab#P#p3.MYI
2008-05-24 09:26 25,585,696 part_tab#P#p4.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p4.MYI
2008-05-24 09:26 25,585,216 part_tab#P#p5.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p5.MYI
2008-05-24 09:26 25,655,740 part_tab#P#p6.MYD
2008-05-24 09:26 8,181,760 part_tab#P#p6.MYI
2008-05-24 09:26 25,586,528 part_tab#P#p7.MYD
2008-05-24 09:26 8,160,256 part_tab#P#p7.MYI
2008-05-24 09:26 25,586,752 part_tab#P#p8.MYD
2008-05-24 09:26 8,160,256 Teil_Tab#P#p8.MYI
2008-05-24 09:26 25,585,824 part_tab#P#p9.MYD
2008-05-24 09:26 8,159,232 part_tab#P#p9.MYI
24.05.2008 09:25 8,608 part_tab.frm
2008-05-24 09:25 68 part_tab.par

Testen Sie die SQL-Leistung erneut

mysql> select count(*) from users_part where „Geburt“ > „1986-01-01“ und „Geburt“ < „1986-12-31“;
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (0,171 Sek.)

mysql> select count(*) from users where `Geburt` > '1986-01-01' und `Geburt` < '1986-12-31';
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (0,583 Sek.)

Hier können wir sehen, dass sich die Leistung der partitionierten Tabelle nach dem Hinzufügen von Indizes zu Schlüsselfeldern und dem Neustart (net stop mysql, net start mysql) leicht verbessert hat. Die Leistungsverbesserung der nicht partitionierten Volltabelle ist am deutlichsten und nähert sich fast der Effizienz der partitionierten Tabelle an.

3.7 Analyse der regionsübergreifenden Ausführungseffizienz

Aus der obigen Analyse können wir erkennen, dass die Effizienz der Ausführung in einer einzelnen Zone deutlich geringer ist als die ohne Partitionierung. Dies liegt daran, dass der Scanbereich nach der Partitionierung reduziert wird.

Was passiert also, wenn wir den oben genannten Bedingungen einen Bereich von Geburtsjahren hinzufügen, um sie regionsübergreifend zu machen? Lassen Sie es uns testen.

mysql> select count(*) from users_part where „Geburt“ > „01.01.1986“ und „Geburt“ < „31.12.1987“;
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (1,914 Sek.)

mysql> select count(*) from users where `Geburt` > '1986-01-01' und `Geburt` < '1987-12-31';
+----------+
| Anzahl(*) |
+----------+
|976324|
+----------+
1 Zeile im Satz (3,871 Sek.)

Es ist ersichtlich, dass die Leistung nach dem Überqueren von Regionen schlechter wird. Es sollte klar sein, dass die Leistung umso schlechter wird, je mehr Cross-Zones vorhanden sind. Daher sollten Sie sich beim Entwerfen von Partitionen dessen bewusst sein und häufige Cross-Zone-Situationen vermeiden sowie die Randbedingungen der Partition sorgfältig beurteilen.

3.8 Zusammenfassung

1. Der partitionierte und unpartitionierte Dateispeicherplatz ist ungefähr gleich (Daten- und Indexdateien).

2. Wenn die Schlüsselfelder in der Abfrageanweisung nicht indiziert sind, ist die Partitionierungszeit viel besser als die Nichtpartitionierungszeit

3. Wenn die Felder in der Abfrageanweisung indiziert sind, verringert sich der Unterschied zwischen Partitionierung und Nichtpartitionierung, es ist jedoch immer noch besser als im Fall der Nichtpartitionierung, und dieser Vorteil wird mit zunehmender Datenmenge deutlicher.

4. Bei großen Datenmengen empfiehlt sich die Verwendung der Partitionierungsfunktion, unabhängig davon, ob sie indiziert sind oder nicht.

5. Laut MySQL-Handbuch verbessert eine Erhöhung von myisam_max_sort_file_size die Partitionsleistung (die maximale Größe der temporären Dateien, die zulässig ist, wenn MySQL den Index neu erstellt).

6. Beurteilen Sie beim Entwerfen von Partitionen die Randbedingungen der Partition sorgfältig, um zu häufige zonenübergreifende Vorgänge zu vermeiden, da sonst die Leistung nicht optimal ist.

4 Detaillierte Erläuterung der Partitionierungsstrategie

4.1 Hash

Die HASH-Partitionierung wird hauptsächlich verwendet, um sicherzustellen, dass die Daten gleichmäßig auf eine vorgegebene Anzahl von Partitionen verteilt werden, während Sie bei der RANGE- und LIST-Partitionierung explizit angeben müssen, in welcher Partition ein bestimmter Spaltenwert oder eine Reihe von Spaltenwerten gespeichert werden soll.

Bei der HASH-Partitionierung erledigt MySQL diese Aufgaben automatisch.

Sie müssen lediglich einen Spaltenwert oder einen Ausdruck basierend auf dem zu hashenden Spaltenwert und die Anzahl der Partitionen angeben, in die die partitionierte Tabelle aufgeteilt werden soll. Hier ist ein Beispiel:

/*Raute*/
Tabelle löschen, wenn `t_userinfo` EXISTIERT;
Tabelle „t_userinfo“ erstellen (
`id` int(10) unsigned NICHT NULL,
`Personencode` varchar(20) DEFAULT NULL,
`Personenname` varchar(100) DEFAULT NULL,
`depcode` varchar(100) DEFAULT NULL,
`depname` varchar(500) DEFAULT NULL,
`gwcode` int(11) DEFAULT NULL,
`gwname` varchar(200) DEFAULT NULL,
`gravalue` varchar(20) DEFAULT NULL,
`createtime` DateTime NICHT NULL
) ENGINE=InnoDB STANDARD-CHARSET=utf8
PARTITION NACH HASH(JAHR(Erstellungszeit))
PARTITIONEN 4(
     PARTITION P0 DATENVERZEICHNIS = '/data0/data' INDEXVERZEICHNIS = '/data0/idx',
     PARTITION P1 DATENVERZEICHNIS = '/data1/data' INDEXVERZEICHNIS = '/data1/idx',
     PARTITION P2 DATENVERZEICHNIS = '/data2/data' INDEXVERZEICHNIS = '/data2/idx',
     PARTITION P3 DATENVERZEICHNIS = '/data3/data' INDEXVERZEICHNIS = '/data3/idx'
);

Im obigen Beispiel wird die HASH-Funktion verwendet, um eine HASH-Operation für das Erstellungsdatum auszuführen und die Daten basierend auf diesem Datum zu partitionieren. Es gibt insgesamt 10 Partitionen.

Fügen Sie der Anweisung zur Tabellenerstellung eine Klausel „PARTITION BY HASH (expr)“ hinzu, wobei „expr“ ein Ausdruck ist, der eine Ganzzahl zurückgibt. Dies kann der Name einer Spalte mit dem Feldtyp „MySQL Integer“ oder ein Ausdruck sein, der eine nicht negative Zahl zurückgibt.

Darüber hinaus müssen Sie möglicherweise am Ende eine Klausel „PARTITIONS num“ hinzufügen, wobei num eine nicht negative Ganzzahl ist, die die Anzahl der Partitionen darstellt, in die die Tabelle aufgeteilt wird.

Jede Partition verfügt über ihr eigenes unabhängiges Daten- und Indexdateispeicherverzeichnis, und die physischen Festplattenpartitionen, in denen sich diese Verzeichnisse befinden, können auch vollständig unabhängig sein, was den Festplatten-E/A-Durchsatz verbessern kann.

4.2 REICHWEITE

Weisen Sie derselben Partition mehrere Zeilen zu, basierend auf Spaltenwerten, die in ein bestimmtes zusammenhängendes Intervall fallen. Diese Intervalle müssen zusammenhängend und dürfen sich nicht überlappen, definiert mit dem Operator VALUES LESS THAN. Hier ist ein Beispiel:

/*Reichweite*/
Tabelle löschen, wenn `t_userinfo` EXISTIERT;
CREATE TABLE `t_userinfo` (
`id` int(10) unsigned NICHT NULL,
`Personencode` varchar(20) DEFAULT NULL,
`Personenname` varchar(100) DEFAULT NULL,
`depcode` varchar(100) DEFAULT NULL,
`depname` varchar(500) DEFAULT NULL,
`gwcode` int(11) DEFAULT NULL,
`gwname` varchar(200) DEFAULT NULL,
`gravalue` varchar(20) DEFAULT NULL,
`createtime` DateTime NICHT NULL
) ENGINE=InnoDB STANDARD-CHARSET=utf8
PARTITION NACH BEREICH(gwcode) (
PARTITION P0 WERTE WENIGER ALS (101) VERZEICHNIS = '/data0/data' INDEX VERZEICHNIS = '/data0/idx',
PARTITION P1 WERTE WENIGER ALS (201) VERZEICHNIS = '/data1/data' INDEX VERZEICHNIS = '/data1/idx',
PARTITION P2 WERTE WENIGER ALS (301) VERZEICHNIS = '/data2/data' INDEX VERZEICHNIS = '/data2/idx',
PARTITION P3 WERTE KLEINER ALS MAXIMALER WERT VERZEICHNIS = '/data3/data' INDEX VERZEICHNIS = '/data3/idx'
);

Im obigen Beispiel wird die RANGE-Funktion verwendet, um die Auftragsnummer in 4 Partitionen zu partitionieren.

Die Positionsnummern 1 bis 100 befinden sich in Partition P0, die Positionen 101 bis 200 in Partition P1 und so weiter. Wenn die Kategorienummer größer als 300 ist, können Sie MAXVALUE verwenden, um alle Daten größer als 300 in Partition P3 zu speichern.

Jede Partition verfügt über ihr eigenes unabhängiges Daten- und Indexdateispeicherverzeichnis, und die physischen Festplattenpartitionen, in denen sich diese Verzeichnisse befinden, können auch vollständig unabhängig sein, was den Festplatten-E/A-Durchsatz verbessern kann.

4.3. Liste (vordefinierte Liste)

Ähnlich wie bei der Partitionierung nach RANGE besteht der Unterschied darin, dass bei der LIST-Partitionierung Partitionen basierend auf Spaltenwerten ausgewählt werden, die mit einem Wert in einem diskreten Wertesatz übereinstimmen. Die LIST-Partitionierung wird mithilfe von „PARTITION BY LIST(expr)“ implementiert, wobei „expr“ ein Spaltenwert oder ein auf einem Spaltenwert basierender Ausdruck ist, der einen ganzzahligen Wert zurückgibt.

Jede Partition wird dann mit „VALUES IN (value_list)“ definiert, wobei „value_list“ eine durch Kommas getrennte Liste von Ganzzahlen ist. Hier ist ein Beispiel:

/*Liste*/
Tabelle löschen, wenn `t_userinfo` EXISTIERT;
CREATE TABLE `t_userinfo` (
`id` int(10) unsigned NICHT NULL,
`Personencode` varchar(20) DEFAULT NULL,
`Personenname` varchar(100) DEFAULT NULL,
`depcode` varchar(100) DEFAULT NULL,
`depname` varchar(500) DEFAULT NULL,
`gwcode` int(11) DEFAULT NULL,
`gwname` varchar(200) DEFAULT NULL,
`gravalue` varchar(20) DEFAULT NULL,
`createtime` DateTime NICHT NULL
) ENGINE=InnoDB STANDARD-CHARSET=utf8
PARTITION BY LIST(`gwcode`) (
PARTITION P0 WERTE IN (46,77,89) DATENVERZEICHNIS = '/data0/data' INDEXVERZEICHNIS = '/data0/idx',
PARTITION P1 WERTE IN (106,125,177) DATENVERZEICHNIS = '/data1/data' INDEXVERZEICHNIS = '/data1/idx',
PARTITION P2 WERTE IN (205,219,289) DATENVERZEICHNIS = '/data2/data' INDEXVERZEICHNIS = '/data2/idx',
PARTITION P3 WERTE IN (302,317,458,509,610) DATENVERZEICHNIS = '/data3/data' INDEXVERZEICHNIS = '/data3/idx'
);

Im obigen Beispiel wird die Listenabgleichfunktion LIST verwendet, um die Stellennummern der Mitarbeiter in 4 Partitionen aufzuteilen. Die Nummern 46, 77 und 89 befinden sich in Partition P0, 106, 125 und 177 in Partition P1 und so weiter.

Im Unterschied zu RANGE müssen die Daten in der LIST-Partition mit der Jobnummer in der zu partitionierenden Liste übereinstimmen, daher ist diese Methode nur für Vergleiche kleiner und bestimmter Intervallwerte geeignet.

Jede Partition verfügt über ihr eigenes unabhängiges Daten- und Indexdateispeicherverzeichnis, und die physischen Festplattenpartitionen, in denen sich diese Verzeichnisse befinden, können auch vollständig unabhängig sein, was den Festplatten-E/A-Durchsatz verbessern kann.

4.4 SCHLÜSSEL

Ähnlich wie bei der HASH-Partitionierung besteht der Unterschied darin, dass die KEY-Partitionierung nur die Berechnung einer oder mehrerer Spalten unterstützt und der MySQL-Server seine eigene Hash-Funktion bereitstellt. Eine oder mehrere Spalten müssen ganzzahlige Werte enthalten. Hier ist ein Beispiel:

/*Schlüssel*/
Tabelle löschen, wenn `t_userinfo` EXISTIERT;
Tabelle „t_userinfo“ erstellen (
`id` int(10) unsigned NICHT NULL,
`Personencode` varchar(20) DEFAULT NULL,
`Personenname` varchar(100) DEFAULT NULL,
`depcode` varchar(100) DEFAULT NULL,
`depname` varchar(500) DEFAULT NULL,
`gwcode` int(11) DEFAULT NULL,
`gwname` varchar(200) DEFAULT NULL,
`gravalue` varchar(20) DEFAULT NULL,
`createtime` DateTime NICHT NULL
) ENGINE=InnoDB STANDARD-CHARSET=utf8
PARTITION NACH SCHLÜSSEL (gwcode)
PARTITIONEN 4(
     PARTITION P0 DATENVERZEICHNIS = '/data0/data' INDEXVERZEICHNIS = '/data0/idx',
     PARTITION P1 DATENVERZEICHNIS = '/data1/data' INDEXVERZEICHNIS = '/data1/idx',
     PARTITION P2 DATENVERZEICHNIS = '/data2/data' INDEXVERZEICHNIS = '/data2/idx',
     PARTITION P3 DATENVERZEICHNIS = '/data3/data' INDEXVERZEICHNIS = '/data3/idx'
);

Hinweis: Dieser Partitionierungsalgorithmus wird derzeit selten verwendet. Es besteht Unsicherheit bei der Verwendung der vom Server bereitgestellten Hash-Funktion, was die spätere Datenstatistik und -sortierung komplizierter macht. Daher verwenden wir lieber den von uns definierten Hash-Ausdruck. Jeder muss nur wissen, dass es ihn gibt und wie man ihn verwendet.

4.5 Verschachtelte Partitionen (Unterpartitionen)

Verschachtelte Partitionen (Unterpartitionen) sind Unterteilungen jeder Partition in einer RANGE/LIST-Partitionstabelle. Die weitere Segmentierung kann vom Typ HASH/KEY usw. sein.

Tabelle löschen, wenn `t_userinfo` EXISTIERT;
CREATE TABLE `t_userinfo` (
`id` int(10) unsigned NICHT NULL,
`Personencode` varchar(20) DEFAULT NULL,
`Personenname` varchar(100) DEFAULT NULL,
`depcode` varchar(100) DEFAULT NULL,
`depname` varchar(500) DEFAULT NULL,
`gwcode` int(11) DEFAULT NULL,
`gwname` varchar(200) DEFAULT NULL,
`gravalue` varchar(20) DEFAULT NULL,
`createtime` DateTime NICHT NULL
) ENGINE=InnoDB STANDARD-CHARSET=utf8
PARTITION NACH BEREICH (id) SUBPARTITION NACH HASH (id% 4) SUBPARTITIONEN 2(
     PARTITION p0 WERTE WENIGER ALS (5000000) DATENVERZEICHNIS = '/data0/data' INDEXVERZEICHNIS = '/data0/idx',
     PARTITION p1 WERTE KLEINER ALS MAXIMALER WERT DATENVERZEICHNIS = '/data1/data' INDEXVERZEICHNIS = '/data1/idx'

);

Wie oben wird die RANGE-Partition weiter in Unterpartitionen unterteilt und die Unterpartitionen verwenden den HASH-Typ.

5 Partitionsverwaltung

5.1 Löschen einer Partition

/*Partition P1 löschen*/
2 ALERT TABLE Benutzerteil DROP PARTITION P1;

5.2 Partitionen neu erstellen

5.2.1 Rekonstruktion der RANGE-Partition

/*Hier führen wir die ursprünglichen Partitionen P0 und P1 in die neue Partition P0 zusammen und setzen den Zustand auf weniger als 5000000 zurück. */
ALTER TABLE users_part REORGANIZE PARTITION P0,P1 IN (PARTITION P0 WERTE KLEINER ALS (5000000));

Wird zum Zusammenführen verwendet, wenn Platz verschwendet wird.

5.2.2 Rekonstruktion der LIST-Partition

/*Fügen Sie die ursprünglichen Partitionen P0 und P1 in die neue Partition P0 zusammen, die der vorherigen ähnelt. */
ALTER TABLE users_part REORGANIZE PARTITION p0,p1 INTO (PARTITION p0 VALUES IN(1,4,5,8,9,12,13,101,555));

5.2.3 Rekonstruktion der HASH/KEY-Partition

/*Die Anzahl der mit REORGANIZE neu aufgebauten Partitionen wird 2. Die Anzahl kann hierbei nur reduziert, nicht jedoch erhöht werden. Wenn Sie mehr hinzufügen möchten, können Sie die Methode ADD PARTITION verwenden. */
ALTER TABLE-Benutzerteil, REORGANIZE PARTITION, COALESCE PARTITION 2;

5.3 Hinzufügen einer neuen Partition

5.3.1 RANGE-Partition hinzufügen

 /*Neue RANGE-Partition hinzufügen*/
 ALTER TABLE Kategorie ADD PARTITION (PARTITION p4 WERTE IN (16,17,18,19) 
 DATENVERZEICHNIS = '/data8/data'
 INDEX-VERZEICHNIS = '/data8/idx');

5.3.2 HASH/KEY-Partition hinzufügen

/* Erweitern Sie die Gesamtzahl der Partitionen auf n. Bitte verwenden Sie stattdessen einen numerischen Wert*/
ALTER TABLE Benutzer_Teil ADD PARTITION PARTITIONS n;

5.3.3 Partitionen zu einer bestehenden Tabelle hinzufügen

alter tableuser_part partition by RANGE (month(birth))
(
PARTITION p0 WERTE KLEINER ALS (1),
PARTITION p1 WERTE KLEINER ALS (2),
PARTITION p2 WERTE KLEINER ALS (3),
PARTITION p3 WERTE KLEINER ALS (4),
PARTITION p4 WERTE WENIGER ALS (5) ,
PARTITION p5 WERTE WENIGER ALS (6) ,
PARTITION p6 WERTE WENIGER ALS (7) ,
PARTITION p7 WERTE WENIGER ALS (8) ,
PARTITION p8 WERTE KLEINER ALS (9) ,
PARTITION p9 WERTE WENIGER ALS (10),
PARTITION p10 WERTE KLEINER ALS (11),
PARTITION p11 WERTE WENIGER ALS (12),
PARTITION P12 WERTE WENIGER ALS (13)
);

6 Entfernen Sie die Einschränkung des Partitionsprimärschlüssels

Die standardmäßige Partitionierungsbeschränkung besteht darin, dass das Partitionierungsfeld Teil des Primärschlüssels (PRIMARY KEY) sein muss. Diese Einschränkung muss entfernt werden.

Wenn in der Tabelle ein Primärschlüssel festgelegt ist, wird die folgende Eingabeaufforderung angezeigt: Ein PRIMÄRSCHLÜSSEL muss alle Spalten in der Partitionierungsfunktion der Tabelle enthalten (Spalten mit Präfix werden nicht berücksichtigt).

Eine Lösung besteht darin, den Primärschlüssel als Partitionierungsbedingung zu verwenden:

ALTER TABLE Benutzerteil PARTITION BY HASH(id) PARTITIONS 4;

Eine andere Möglichkeit besteht darin, dem Primärschlüssel das Partitionsbedingungsfeld hinzuzufügen, um ihn in einen gemeinsamen Primärschlüssel umzuwandeln. Wie unten gezeigt, bilden ID und GWCode einen gemeinsamen Primärschlüssel:

 Tabelle ändern, Benutzerteil, Primärschlüssel löschen;
 Tabelle „Benutzerteil“ ändern, PRIMARY KEY (ID, GW-Code) hinzufügen;

Dies ist das Ende dieses Artikels über die Verwendung der Partitionsfunktion in MySQL zur Implementierung einer horizontalen Partitionierung. Weitere Informationen zur horizontalen MySQL-Partitionierung finden Sie in früheren Artikeln auf 123WORDPRESS.COM oder in den folgenden verwandten Artikeln. Ich hoffe, Sie werden 123WORDPRESS.COM auch in Zukunft unterstützen!