MySQLはPartition関数を使用して水平分割戦略を実装します。

1件のレビュー

前のセクションでは、垂直分割 (スケールアップ) と水平分割 (スケールアウト) を含むデータベースのパーティション分割方法について詳しく説明しました。また、水平分割のいくつかの戦略についても簡単にまとめました。それでは、それらを確認してみましょう。

2 水平分割の5つの戦略

2.1 ハッシュ

この戦略は、テーブルの 1 つ以上の列のハッシュキーを計算し、最終的にハッシュコードの異なる値に対応するデータ領域をパーティション分割することです。たとえば、テーブル内の日付の年を分割して、各年が 1 つの間隔にクラスター化されるようにする戦略を作成できます。

 ハッシュによるパーティション(YEAR(createtime))
 パーティション 10

2.2 範囲

この戦略は、データを異なる範囲に分割することです。たとえば、数千万件のデータを含むテーブルを ID ごとに 4 つのパーティションに分割し、各パーティションに約 500 万件のデータを格納し、750 万件を超えるデータはすべて 4 番目のパーティションに配置することができます。

範囲によるパーティション(id) (
 PARTITIONP0の値は(2500001)未満です。
 PARTITIONP1の値は(5000001)未満です。
 PARTITIONp2 の値は(7500001)未満です。
 PARTITIONp3 の値が MAXVALUE 未満です
 ）

2.3. キー

ハッシュ戦略の拡張であり、ハッシュキーは MySQL システムによって生成されます。

2.4. リスト（定義済みリスト）

この戦略により、システムは定義されたリストに対応する値で行を分割できます。たとえば、ジョブコードに応じてエリアを分割し、異なるジョブタイプのコードを異なるパーティションに対応させることで、分割統治の目的を達成します。

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

上記の SQL スクリプトは、リストマッチング LIST 関数を使用して、従業員の職位番号を 4 つのパーティションに分割します。番号 46、77、89 の管理職はパーティション P0 に、番号 106、125、177 の技術職はパーティション P1 に、というように続きます。

2.5. 複合

複合モードは、実際には上記のモードを組み合わせたものです。たとえば、範囲に基づいてハッシュパーティション分割を実行できます。

3 テスト範囲戦略

3.1 マスターテーブルとサブテーブルを作成する

共通ユーザーテーブル users を作成し、次にパーティションテーブル users_part を作成して、1980 年代に生まれたユーザーを年ごとにパーティション化します。

3.1.1 要約表の記述

mysql> テーブルユーザーを作成
（
 "id" int(10) 符号なし NOT NULL,
  "name" varchar(100) デフォルト NULL,
  「誕生」日時
)ENGINE=InnoDB デフォルト文字セット=utf8;
クエリは正常です。影響を受けた行は 0 行です

3.1.2 テーブル分割ステートメント

最後の行では、1989 年以降に生まれたすべてのユーザーを 10 番目のパーティションに割り当てていることに注意してください。1980 年代に生まれたユーザーをシミュレートしており、実際のビジネスは特定の状況に応じて分割されます。

 mysql>テーブルusers_partを作成
 （
   "id" int(10) 符号なし NOT NULL,
    "name" varchar(100) デフォルト NULL,
    「誕生」日時
  ) エンジン=InnoDB デフォルト文字セット=utf8
  範囲によるパーティション (年(誕生)) (
  パーティションp0の値が小さい（1981）、
  パーティション p1 値が小さい (1982)、
 パーティション p2 値が小さい (1983)、
 パーティション p3 値が小さい (1984)、
 パーティション p4 値が小さい (1985)、
 パーティション p5 値が小さい (1986)、
パーティション p6 値が小さい (1987)、
 パーティション p7 値が小さい (1988)、
 パーティション p8 の値は (1989) より小さい、17 パーティション p9 の値は MAXVALUE より小さい
 );
 クエリは正常です。影響を受けた行は 0 行です

3.2 テーブルデータの初期化

関数またはストアドプロシージャを使用してデータを一括初期化し、ここに 1,000 万個のデータを挿入できます。

init_users_part が存在する場合はプロシージャを削除します。

区切り文字 $ /* 文の終了文字を $* に設定します/
プロシージャ init_users_part() を作成します。
 始める
  srt int default 0 を宣言します。
  その間
    srt < 10000000 /* 1000W のデータを書き込むように設定します*/
   する
  insert into `users_part` values (srt, concat('username_',idx1),adddate('1980-01-01',rand() * 3650)); /*10年以内の値をランダムに選択*/
 srt = srt + 1 を設定します。
 終了しながら;
 終了$
区切り文字 ;


init_users_part() を呼び出します。

3.3 テーブル全体にデータを同期する

mysql> insert into users select * from users_part; // 1,000 万のデータをパーティション化されていない完全なテーブル users にコピーします。クエリは正常に実行され、10000000 行が影響を受けました (51.59 秒) 

 レコード: 10000000 重複: 0 警告: 0

3.4 SQL実行の効率をテストする

mysql> users_part から count(*) を選択します。 where `birth` > '1986-01-01' かつ `birth` < '1986-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット内1列（0.335秒）
mysql> select count(*) from users where `birth` > '1986-01-01' and `birth` < '1986-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット1列目（5.187秒）

結果は非常に明確です。パーティション化されたテーブルの実行効率は確かに高く、実行時間はパーティション化されていないテーブルの 1/10 未満です。

3.5 Explainを使用して計画分析を実行する

mysql> explain select count(*) from users_part where `birth` > '1986-01-01' and `birth` < '1986-12-31';
+----+--------------+-------------+-----------+---------+---------------+-------+--------+---------+-----------+------------+-------------+
| id | select_type | テーブル | パーティション | タイプ | 可能なキー | キー | キー長 | ref | 行 | フィルター済み | 追加 |
+----+--------------+-------------+-----------+---------+---------------+-------+--------+---------+-----------+------------+-------------+
| 1 | SIMPLE | users_part | p7 | ALL | NULL | NULL | NULL | NULL | 987769| 100.00 | where の使用 |
+----+--------------+-------------+-----------+---------+---------------+-------+--------+---------+-----------+------------+-------------+
セットに 1 行、警告 1 件 (0.00 秒)

mysql> explain select count(*) from users where `birth` > '1986-01-01' and `birth` < '1986-12-31';
+----+-------------+--------+-----------+---------+---------------+-------+----------+----------+------------+-------------+
| id | select_type | テーブル | パーティション | タイプ | 可能なキー | キー | キー長 | ref | 行 | フィルター済み | 追加 |
+----+-------------+--------+-----------+---------+---------------+-------+----------+----------+------------+-------------+
| 1 | SIMPLE | ユーザー | NULL | ALL | NULL | NULL | NULL | NULL |10000000 | 100.00 | where の使用 |
+----+-------------+--------+-----------+---------+---------------+-------+----------+----------+------------+-------------+
セットに 1 行、警告 1 件 (0.00 秒)

ここでは、2 つの重要なパラメータに注目します。1 つはパーティションです。users_part では p7 であり、これはデータが 7 番目のパーティションで取得されることを意味します。users テーブルは null であり、これはパーティションなしのフルエリアスキャンであることを意味します。

もう 1 つのパラメータは、スキャンされると予測される行数である行です。users テーブルは明らかに完全なテーブルスキャンです。

3.6 インデックス作成効率の向上

パーティショニングと条件付きクエリに birth フィールドを使用するため、効率を最適化するために birth フィールドにインデックスを作成します。

mysql> users(birth) に idx_user インデックスを作成します。
クエリは正常、影響を受けた行は 0 行 (1 分 7.04 秒)
レコード: 10000000 重複: 0 警告: 0

mysql> users_part(birth) に idx_user_part インデックスを作成します。
クエリは正常、影響を受けた行は 0 行 (1 分 1.05 秒)
レコード: 10000000 重複: 0 警告: 0

インデックス作成後のデータベースファイルサイズのリスト:

2008-05-24 09:23 8,608 no_part_tab.frm
2008-05-24 09:24 255,999,996 ノーパートタブ.MYD
2008-05-24 09:24 81,611,776 no_part_tab.MYI
2008-05-24 09:25 0 パートタブ#P#p0.MYD
2008-05-24 09:26 1,024 パートタブ#P#p0.MYI
2008-05-24 09:26 25,550,656 パートタブ#P#p1.MYD
2008-05-24 09:26 8,148,992 パートタブ#P#p1.MYI
2008-05-24 09:26 25,620,192 パートタブ#P#p10.MYD
2008-05-24 09:26 8,170,496 パートタブ#P#p10.MYI
2008-05-24 09:25 0 パートタブ#P#p11.MYD
2008-05-24 09:26 1,024 パートタブ#P#p11.MYI
2008-05-24 09:26 25,656,512 パートタブ#P#p2.MYD
2008-05-24 09:26 8,181,760 パートタブ#P#p2.MYI
2008-05-24 09:26 25,586,880 パートタブ#P#p3.MYD
2008-05-24 09:26 8,160,256 パートタブ#P#p3.MYI
2008-05-24 09:26 25,585,696 パートタブ#P#p4.MYD
2008-05-24 09:26 8,159,232 パートタブ#P#p4.MYI
2008-05-24 09:26 25,585,216 パートタブ#P#p5.MYD
2008-05-24 09:26 8,159,232 パートタブ#P#p5.MYI
2008-05-24 09:26 25,655,740 パートタブ#P#p6.MYD
2008-05-24 09:26 8,181,760 パートタブ#P#p6.MYI
2008-05-24 09:26 25,586,528 パートタブ#P#p7.MYD
2008-05-24 09:26 8,160,256 パートタブ#P#p7.MYI
2008-05-24 09:26 25,586,752 パートタブ#P#p8.MYD
2008-05-24 09:26 8,160,256 パートタブ#P#p8.MYI
2008-05-24 09:26 25,585,824 パートタブ#P#p9.MYD
2008-05-24 09:26 8,159,232 パートタブ#P#p9.MYI
2008-05-24 09:25 8,608 パートタブ.frm
2008-05-24 09:25 68 パートタブ.par

SQLパフォーマンスを再度テストする

mysql> users_part から count(*) を選択します。 where `birth` > '1986-01-01' かつ `birth` < '1986-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット内1列（0.171秒）

mysql> select count(*) from users where `birth` > '1986-01-01' and `birth` < '1986-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット内1列（0.583秒）

ここで、キーフィールドにインデックスを追加して再起動 (net stop mysql、net start mysql) すると、パーティションテーブルのパフォーマンスがわずかに向上したことがわかります。パーティション化されていない完全なテーブルのパフォーマンスの向上は最も顕著で、パーティション化されたテーブルの効率にほぼ近づいています。

3.7 地域間実行効率の分析

上記の分析から、単一ゾーンで実行した場合の効率は、パーティション分割しない場合に比べて大幅に低下することがわかります。これは、パーティション分割後にスキャン範囲が縮小されるためです。

では、上記の条件に誕生年の範囲を追加して地域横断的にするとどうなるでしょうか? テストしてみましょう。

mysql> users_part から count(*) を選択します。 where `birth` > '1986-01-01' かつ `birth` < '1987-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット内1列（1.914秒）

mysql> select count(*) from users where `birth` > '1986-01-01' and `birth` < '1987-12-31';
+----------+
| カウント(*) |
+----------+
|976324|
+----------+
セット1行目（3.871秒）

領域を越えるとパフォーマンスが悪くなることがわかります。クロスゾーンの数が増えるほど、パフォーマンスが低下することを理解する必要があります。したがって、パーティションを設計するときは、この点に注意し、クロスゾーンの状況が頻繁に発生することを避け、パーティションの境界条件を慎重に判断する必要があります。

3.8 まとめ

1. パーティション化されたファイルとパーティション化されていないファイルのスペースはほぼ同じです（データファイルとインデックスファイル）

2. クエリステートメントのキーフィールドにインデックスが付いていないと、パーティション分割の時間はパーティション分割しない場合の時間よりもはるかに短くなります。

3. クエリステートメント内のフィールドにインデックスが付けられている場合、パーティション分割と非パーティション分割の違いは縮小されますが、それでも非パーティション分割の場合よりも優れており、この利点はデータ量が増えるにつれてより明らかになります。

4. 大量のデータの場合は、インデックスの有無にかかわらず、パーティション分割機能を使用することをお勧めします。

5. MySQLのマニュアルによると、myisam_max_sort_file_sizeを増やすとパーティションのパフォーマンスが向上します（MySQLがインデックスを再構築するときに許可される一時ファイルの最大サイズ）

6. パーティションを設計するときは、パーティションの境界条件を慎重に判断して、過度に頻繁なゾーン間操作を回避してください。そうしないと、パフォーマンスが最適ではなくなります。

4 パーティショニング戦略の詳細な説明

4.1 ハッシュ

HASH パーティション分割は主に、データが所定の数のパーティション間で均等に分散されるようにするために使用されますが、RANGE および LIST パーティション分割では、特定の列値または列値のセットをどのパーティションに格納するかを明示的に指定する必要があります。

HASH パーティショニングでは、MySQL がこれらのタスクを自動的に完了します。

ハッシュする列値と、パーティション化されたテーブルを分割するパーティションの数に基づいて、列値または式を指定するだけです。次に例を示します。

/*ハッシュ*/
`t_userinfo` が存在する場合はテーブルを削除します。
テーブル `t_userinfo` を作成します (
`id` int(10) 符号なし NOT NULL,
`personcode` varchar(20) デフォルト NULL,
`personname` varchar(100) デフォルト NULL,
`depcode` varchar(100) デフォルト NULL,
`depname` varchar(500) デフォルト NULL,
`gwcode` int(11) デフォルト NULL,
`gwname` varchar(200) デフォルト NULL,
`gravalue` varchar(20) デフォルト NULL,
`createtime` DateTime は NULL ではありません
) エンジン=InnoDB デフォルト文字セット=utf8
ハッシュによるパーティション(YEAR(createtime))
パーティション 4(
     パーティション P0 データディレクトリ = '/data0/data' インデックスディレクトリ = '/data0/idx'、
     パーティション P1 データディレクトリ = '/data1/data' インデックスディレクトリ = '/data1/idx'、
     パーティション P2 データディレクトリ = '/data2/data' インデックスディレクトリ = '/data2/idx'、
     パーティション P3 データ ディレクトリ = '/data3/data' インデックス ディレクトリ = '/data3/idx'
);

上記の例では、HASH 関数を使用して、createtime 日付に対して HASH 操作を実行し、この日付に基づいてデータをパーティション分割します。パーティションは合計 10 個あります。

テーブル作成ステートメントに「PARTITION BY HASH (expr)」句を追加します。ここで、「expr」は整数を返す式です。これは、MySQL 整数のフィールドタイプを持つ列の名前、または負でない数値を返す式にすることができます。

さらに、最後に「PARTITIONS num」句を追加する必要がある場合もあります。ここで、num は、テーブルが分割されるパーティションの数を表す負でない整数です。

各パーティションには独自の独立したデータおよびインデックスファイルストレージディレクトリがあり、これらのディレクトリが配置されている物理ディスクパーティションも完全に独立しているため、ディスク IO スループットが向上します。

4.2 範囲

指定された連続した間隔内にある列値に基づいて、同じパーティションに複数の行を割り当てます。これらの間隔は、VALUES LESS THAN 演算子を使用して定義され、連続していて重複していない必要があります。次に例を示します。

/*範囲*/
`t_userinfo` が存在する場合はテーブルを削除します。
テーブル `t_userinfo` を作成します (
`id` int(10) 符号なし NOT NULL,
`personcode` varchar(20) デフォルト NULL,
`personname` varchar(100) デフォルト NULL,
`depcode` varchar(100) デフォルト NULL,
`depname` varchar(500) デフォルト NULL,
`gwcode` int(11) デフォルト NULL,
`gwname` varchar(200) デフォルト NULL,
`gravalue` varchar(20) デフォルト NULL,
`createtime` DateTime は NULL ではありません
) エンジン=InnoDB デフォルト文字セット=utf8
範囲によるパーティション(gwcode) (
パーティション P0 値が(101)未満 ディレクトリ = '/data0/data' インデックス ディレクトリ = '/data0/idx'、
パーティション P1 値が(201)未満 ディレクトリ = '/data1/data' インデックス ディレクトリ = '/data1/idx'、
パーティション P2 値が(301)未満 ディレクトリ = '/data2/data' インデックス ディレクトリ = '/data2/idx'、
パーティション P3 の値が MAXVALUE 未満です ディレクトリ = '/data3/data' インデックス ディレクトリ = '/data3/idx'
);

上記の例では、RANGE 関数を使用してジョブ番号を 4 つのパーティションに分割しています。

位置番号 1 ～ 100 はパーティション P0 にあり、位置 101 ～ 200 はパーティション P1 にあります。カテゴリ番号が 300 より大きい場合は、MAXVALUE を使用して、300 より大きいすべてのデータをパーティション P3 に格納できます。

4.3、LIST（定義済みリスト）

RANGE によるパーティション分割と似ていますが、違いは、LIST パーティション分割では、離散的な値セット内の値と一致する列値に基づいてパーティションを選択することです。 LIST パーティション分割は、「PARTITION BY LIST(expr)」を使用して実装されます。ここで、「expr」は列値、または整数値を返す列値に基づく式です。

次に、各パーティションは「VALUES IN (value_list)」を使用して定義されます。ここで、「value_list」はコンマで区切られた整数のリストです。次に例を示します。

/*リスト*/
`t_userinfo` が存在する場合はテーブルを削除します。
テーブル `t_userinfo` を作成します (
`id` int(10) 符号なし NOT NULL,
`personcode` varchar(20) デフォルト NULL,
`personname` varchar(100) デフォルト NULL,
`depcode` varchar(100) デフォルト NULL,
`depname` varchar(500) デフォルト NULL,
`gwcode` int(11) デフォルト NULL,
`gwname` varchar(200) デフォルト NULL,
`gravalue` varchar(20) デフォルト NULL,
`createtime` DateTime は NULL ではありません
) エンジン=InnoDB デフォルト文字セット=utf8
リストによるパーティション(`gwcode`) (
パーティション P0 値 (46,77,89) データディレクトリ = '/data0/data' インデックスディレクトリ = '/data0/idx'、
パーティション P1 値 (106,125,177) データディレクトリ = '/data1/data' インデックスディレクトリ = '/data1/idx'、
パーティション P2 値 (205,219,289) データディレクトリ = '/data2/data' インデックスディレクトリ = '/data2/idx'、
パーティション P3 値 (302,317,458,509,610) データ ディレクトリ = '/data3/data' インデックス ディレクトリ = '/data3/idx'
);

上記の例では、リストマッチング LIST 関数を使用して、従業員の役職番号を 4 つのパーティションに分割しています。番号 46、77、89 はパーティション P0 に、106、125、177 はパーティション P1 にあります。

RANGE とは異なり、LIST パーティション内のデータは、パーティション化されるリスト内のジョブ番号と一致する必要があるため、この方法は小さく特定の間隔値の比較にのみ適しています。

4.4 キー

HASH パーティショニングと同様ですが、KEY パーティショニングでは 1 つ以上の列の計算のみがサポートされ、MySQL サーバーが独自のハッシュ関数を提供する点が異なります。 1 つ以上の列に整数値が含まれている必要があります。次に例を示します。

/*鍵*/
`t_userinfo` が存在する場合はテーブルを削除します。
テーブル `t_userinfo` を作成します (
`id` int(10) 符号なし NOT NULL,
`personcode` varchar(20) デフォルト NULL,
`personname` varchar(100) デフォルト NULL,
`depcode` varchar(100) デフォルト NULL,
`depname` varchar(500) デフォルト NULL,
`gwcode` int(11) デフォルト NULL,
`gwname` varchar(200) デフォルト NULL,
`gravalue` varchar(20) デフォルト NULL,
`createtime` DateTime は NULL ではありません
) エンジン=InnoDB デフォルト文字セット=utf8
キーによるパーティション(gwcode)
パーティション 4(
     パーティション P0 データディレクトリ = '/data0/data' インデックスディレクトリ = '/data0/idx'、
     パーティション P1 データディレクトリ = '/data1/data' インデックスディレクトリ = '/data1/idx'、
     パーティション P2 データディレクトリ = '/data2/data' インデックスディレクトリ = '/data2/idx'、
     パーティション P3 データ ディレクトリ = '/data3/data' インデックス ディレクトリ = '/data3/idx'
);

注: このパーティショニングアルゴリズムは現在ほとんど使用されていません。サーバーが提供するハッシュ関数を使用すると不確実性が生じ、後続のデータ統計とソートが複雑になります。そのため、弊社で定義したハッシュ式を使用することをお勧めします。誰もがその存在と使用方法を知っていればよいのです。

4.5 ネストされたパーティション（サブパーティション）

ネストされたパーティション (サブパーティション) は、RANGE/LIST パーティションテーブル内の各パーティションの細分化です。さらなるセグメンテーションは、HASH/KEY などのタイプにすることができます。

`t_userinfo` が存在する場合はテーブルを削除します。
テーブル `t_userinfo` を作成します (
`id` int(10) 符号なし NOT NULL,
`personcode` varchar(20) デフォルト NULL,
`personname` varchar(100) デフォルト NULL,
`depcode` varchar(100) デフォルト NULL,
`depname` varchar(500) デフォルト NULL,
`gwcode` int(11) デフォルト NULL,
`gwname` varchar(200) デフォルト NULL,
`gravalue` varchar(20) デフォルト NULL,
`createtime` DateTime は NULL ではありません
) エンジン=InnoDB デフォルト文字セット=utf8
範囲によるパーティション (id) ハッシュによるサブパーティション (id% 4) サブパーティション 2(
     パーティション p0 の値は (5000000) 未満です データ ディレクトリ = '/data0/data' インデックス ディレクトリ = '/data0/idx'、
     パーティション p1 の値は MAXVALUE 未満です データ ディレクトリ = '/data1/data' インデックス ディレクトリ = '/data1/idx'

);

上記のように、RANGE パーティションはさらにサブパーティションに分割され、サブパーティションでは HASH タイプが使用されます。

5 パーティション管理

5.1 パーティションの削除

/*パーティションP1を削除*/
2 アラート テーブル users_part DROP PARTITION P1;

5.2 パーティションの再構築

5.2.1 RANGEパーティションの再構築

/*ここでは、元の P0 パーティションと P1 パーティションを新しい P0 パーティションにマージし、条件を 5000000 未満にリセットします。 */
ALTER TABLE users_part パーティション P0,P1 を (パーティション P0 の値が (5000000) 未満) に再編成します。

スペースが無駄になっている状況をマージするために使用されます。

5.2.2 LISTパーティションの再構築

/* 元の P0 パーティションと P1 パーティションを、前のパーティションに似た新しい P0 パーティションにマージします。 */
ALTER TABLE users_part で、パーティション p0、p1 を (パーティション p0 の値が (1、4、5、8、9、12、13、101、555) になるように) 再編成します。

5.2.3 HASH/KEYパーティションの再構築

/* REORGANIZE を使用して再構築されるパーティションの数は 2 になります。ここでは、数を減らすことはできますが、増やすことはできません。さらに追加したい場合は、ADD PARTITION メソッドを使用できます。 */
ALTER TABLE users_part でパーティションを再編成し、パーティション 2 を結合します。

5.3 新しいパーティションの追加

5.3.1 RANGEパーティションの追加

 /*新しいRANGEパーティションを追加する*/
 ALTER TABLE カテゴリ ADD PARTITION (PARTITION p4 VALUES IN (16,17,18,19) 
 データディレクトリ = '/data8/data'
 インデックスディレクトリ = '/data8/idx');

5.3.2 HASH/KEYパーティションの追加

/* パーティションの合計数を n に拡張します。代わりに数値を使用してください*/
ALTER TABLE users_part にパーティション PARTITIONS n を追加します。

5.3.3 既存のテーブルにパーティションを追加する

tableuser_part のパーティションを RANGE (month(birth)) で変更します。
（
パーティションp0の値が(1)未満の場合、
パーティションp1の値が(2)未満である、
パーティションp2の値が(3)未満である、
パーティションp3の値は（4）未満です。
パーティションp4の値は（5）未満です。
パーティションp5の値が（6）未満である、
パーティションp6の値は（7）未満です。
パーティション p7 値が (8) 未満、
パーティション p8 値が (9) 未満、
パーティション p9 値が (10) 未満、
パーティションp10の値は（11）より小さい。
パーティション p11 値が (12) 未満の場合、
パーティションP12の値が(13)より小さい
);

6 パーティションの主キー制限を削除する

デフォルトのパーティション制限では、パーティションフィールドは主キー (PRIMARY KEY) の一部である必要があります。この制限は削除する必要があります。

テーブルに主キーが設定されている場合は、次のプロンプトが表示されます: 主キーには、テーブルのパーティション関数内のすべての列を含める必要があります (プレフィックス付きの列は考慮されません)。

1 つの解決策は、パーティション条件として主キーを使用することです。

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

もう 1 つの方法は、パーティション条件フィールドを主キーに追加して、それを共同主キーに変換することです。以下に示すように、id と gwcode は共同主キーを形成します。

 テーブル users_part を変更し、PRIMARY KEY を削除します。
 テーブル users_part を変更し、PRIMARY KEY(id, gwcode) を追加します。

これで、MySQL の Partition 関数を使用して水平パーティショニングを実装する方法についての説明は終了です。MySQL の水平パーティショニングの詳細については、123WORDPRESS.COM の以前の記事を検索するか、次の関連記事を引き続き参照してください。今後とも 123WORDPRESS.COM をよろしくお願いいたします。

以下もご興味があるかもしれません: