すべてのプロダクト
Search
ドキュメントセンター

PolarDB:CREATE TABLE

最終更新日:May 28, 2024

CREATE TABLEステートメントを実行して、テーブルを作成できます。 このトピックでは、CREATE TABLEステートメントの構文と、CREATE TABLEステートメントで使用できる句、パラメーター、および基本メソッドについて説明します。

使用上の注意

  • PolarDB-X 1.0インスタンスでは、DDLステートメントを実行してデータベースを直接作成することはできません。 データベースは、PolarDB-Xコンソールでのみ作成できます。 詳細については、以下をご参照ください。 データベースの作成
  • PolarDB-X 1.0インスタンスは、MySQLバージョンが5.7以降で、PolarDB-X 1.0インスタンスバージョンが5.4.1以降の場合にのみ、グローバルセカンダリインデックス (GSI) をサポートします。 GSIの詳細については、 グローバルセカンダリインデックス
  • PolarDB-Xは、プライマリキー値がテーブルシャードで一意であることを保証しますが、データベースシャードでは一意ではありません。 必要に応じて、一意のGSIを作成できます。
CREATE [シャドウ] TABLE [存在しない場合] tbl_name
    (create_definition, ...)
    [table_options]
    [drds_partition_options]

create_definition:
    col_name column_definition
  | mysql_create_definition
  | [UNIQUE] グローバルインデックスindex_name [index_type] (index_sharding_col_name,...)
      [global_secondary_index_option]
      [index_option] ...

# GSI関連の構文
global_secondary_index_option:
    [COVERING (col_name,...)]
    [drds_partition_options]

# シャーディングのための句
drds_partition_options:
    db_partition_algorithmによるDBPARTITION
    [TBPARTITION BY table_partition_algorithm [TBPARTITIONS num]]

db_sharding_algorithm:
    HASH([col_name])
  | {YYYYMM | YYYYWEEK | YYYYDD | YYYYMM_OPT | YYYYWEEK_OPT | YYYYDD_OPT}(col_name)
  | UNI_HASH(col_name)
  | RIGHT_SHIFT(col_name, n)
  | RANGE_HASH(col_name, col_name, n)

table_sharding_algorithm:
    HASH(col_name)
  | {MM | DD | WEEK | MMDD | YYYYMM | YYYYWEEK | YYYYYYWEEK | YYYYMM_OPT | YYYYYYWEEK_OPT | YYYYDD_OPT}(col_name)
  | UNI_HASH(col_name)
  | RIGHT_SHIFT(col_name, n)
  | RANGE_HASH(col_name, col_name, n)

# MySQL DDL構文
index_sharding_col_name:
    col_name [(length)] [ASC | DESC]

index_option:
    KEY_BLOCK_SIZE [=] 値
  | index_type
  | PARSER parser_name付き
  | コメント '文字列'

index_type:
    USING {BTREE | ハッシュ} 
説明 PolarDB-X 1.0 DDL構文は、MySQL構文に基づいています。 上記のコードには、MySQL構文とは異なる構文がリストされています。 構文の詳細については、「MySQLドキュメント」をご参照ください。

シャーディングの句とパラメータ

  • DBPARTITION BY hash(partition_key): この句は、データベースシャードキーとデータベースシャーディングアルゴリズムを指定します。
  • TBPARTITION BY { HASH (列) | {MM | DD | WEEK | MMDD | YYYYMM | YYYYWEEK | YYYYYYMM_OPT | YYYYYYWEEK_OPT | YYYYDD_OPT}(列): オプション。 この句は、データを物理テーブルにマップするために使用されるメソッドを指定します。 この句は、デフォルトでDBPARTITION BY句と同じです。
  • TBPARTITIONS num: オプション。 各データベースの物理テーブルの数を指定します。 デフォルト値は 1 です。 テーブルシャーディングが不要な場合は、このパラメーターを指定する必要はありません。
  • シャーディング関数の詳細については、「概要」をご参照ください。

GSI定義句

  • [UNIQUE] GLOBAL: GSIを定義します。 UNIQUE GLOBALは、インデックスがグローバルに一意のインデックスであることを指定します。
  • index_name: インデックスの名前。 指定された名前は、インデックステーブルの名前と同じです。
  • index_type: インデックステーブル内のシャードキーのローカルセカンダリインデックスの型。 サポートされているローカルセカンダリインデックスの種類の詳細については、「MySQLドキュメント」をご参照ください。
  • index_sharding_col_name,...: インデックス列。 インデックス列には、インデックステーブルのすべてのシャードキー列のみが含まれます。 詳細については、「」をご参照ください。 グローバルセカンダリインデックス
  • global_secondary_index_option: PolarDB-X 1.0 GSIの拡張構文。
    • COVERING (col_name,...): カバーする列。 カバー列は、インデックス列を除くインデックステーブルのすべての列を含む。 既定では、カバー列には、プライマリテーブルのプライマリキー列とシャードキー列が含まれます。 詳細については、「」をご参照ください。 グローバルセカンダリインデックス
    • drds_partition_options: インデックステーブルをシャーディングするための句。 詳細については、「シャーディングの節とパラメーター」をご参照ください。
  • index_option: インデックステーブルのシャードキーのローカルインデックスの属性。 詳細については、「MySQLドキュメント」をご参照ください。

フルリンク・ストレス・テスト用のShadow table句

SHADOW: フルリンクのストレステストに使用できるシャドウテーブルを作成します。 テーブル名の先頭に _test_ を付ける必要があります。 プレフィックスに続くテーブル名と、関連付けられた仮テーブルの名前は一致している必要があります。 シャドウテーブルを作成する前に、仮テーブルを作成する必要があります。

非シャードテーブルの作成

非シャードテーブルを作成します。 テーブルは論理テーブルである。 シャーディングは必要ありません。

CREATE TABLE single_tbl (
 id bigint not null auto_increment, 
 名前varchar(30) 、 
 主キー (id)
); 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、非シャードテーブルがデータベース0に作成されていることを示しています。

mysql> single_tblからトポロジを表示します。------ ------------------------------------------------------------------ -------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ -------------
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | single_tbl |
------ ------------------------------------------------------------------ -------------
セットの1列 (0.01秒)
            

テーブルシャーディングではなくデータベースシャーディングのみが実行されるテーブルを作成する

たとえば、8つのデータベースシャードが作成されます。 テーブルシャーディングではなくデータベースシャーディングのみが実行され、ID列に基づいてデータベースシャーディング方法としてハッシュが実行されるテーブルを作成します。 テーブルは論理テーブルである。

CREATE TABLE multi_db_single_tbl (
  id bigint not null auto_increment, 
  名前varchar(30) 、 
  主キー (id)
) dbpartition by hash(id); 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、各データベースシャードに1つのテーブルシャードが作成されることを示しています。 これは、データベースシャーディングのみが実行されることを示します。

mysql> multi_db_single_tblからトポロジを表示します。+ ------ + ------------------------------------------------------------------ + --------------------- +
| ID | GROUP_NAME | テーブル名 |
+ ------ + ------------------------------------------------------------------ + --------------------- +
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | multi_db_single_tbl |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | multi_db_single_tbl |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0002_RDS | multi_db_single_tbl |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0003_RDS | multi_db_single_tbl |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0004_RDS | multi_db_single_tbl |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0005_RDS | multi_db_single_tbl |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0006_RDS | multi_db_single_tbl |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | multi_db_single_tbl |
+ ------ + ------------------------------------------------------------------ + --------------------- +
セットの8行 (0.01秒) 

データベースシャーディングとテーブルシャーディングが実行されるテーブルを作成する

次のいずれかのシャーディング方法を使用して、データベースシャーディングとテーブルシャーディングが実行されるテーブルを作成できます。

説明 次の例では、作成された8つのデータベースシャードが使用されています。

シャーディングにハッシュ関数を使用する

データベースシャーディングとテーブルシャーディングが実行されるテーブルを作成します。 テーブルは論理テーブルである。 各データベースシャードには3つの物理テーブルがあります。 ハッシュは、ID列に基づくデータベースシャーディング方法として、および入札列に基づくテーブルシャーディング方法として実行される。 ID列のデータに対してハッシュ操作を実行して、データを8つのデータベースシャードに分散します。 次に、bid列のデータに対してハッシュ操作を実行して、各データベースシャードの3つの物理テーブルにデータを配布します。

CREATE TABLE multi_db_multi_tbl (
 id bigint not null auto_increment, 
 bid int, 
 名前varchar(30) 、 
 主キー (id)
) dbpartition by hash(id) tbpartition by hash(bid) tbpartitions 3; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、各データベースシャードに3つのテーブルシャードが作成されていることを示しています。

mysql> multi_db_multi_tblからトポロジを表示します。+ ------ + ------------------------------------------------------------------ + ----------------------- +
| ID | GROUP_NAME | テーブル名 |
+ ------ + ------------------------------------------------------------------ + ----------------------- +
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | multi_db_multi_tbl_00 |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | multi_db_multi_tbl_01 |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | multi_db_multi_tbl_02 |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | multi_db_multi_tbl_03 |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | multi_db_multi_tbl_04 |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | multi_db_multi_tbl_05 |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0002_RDS | multi_db_multi_tbl_06 |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0002_RDS | multi_db_multi_tbl_07 |
| 8 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0002_RDS | multi_db_multi_tbl_08 |
| 9 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0003_RDS | multi_db_multi_tbl_09 |
| 10 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0003_RDS | multi_db_multi_tbl_10 |
| 11 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0003_RDS | multi_db_multi_tbl_11 |
| 12 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0004_RDS | multi_db_multi_tbl_12 |
| 13 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0004_RDS | multi_db_multi_tbl_13 |
| 14 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0004_RDS | multi_db_multi_tbl_14 |
| 15 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0005_RDS | multi_db_multi_tbl_15 |
| 16 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0005_RDS | multi_db_multi_tbl_16 |
| 17 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0005_RDS | multi_db_multi_tbl_17 |
| 18 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0006_RDS | multi_db_multi_tbl_18 |
| 19 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0006_RDS | multi_db_multi_tbl_19 |
| 20 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0006_RDS | multi_db_multi_tbl_20 |
| 21 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | multi_db_multi_tbl_21 |
| 22 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | multi_db_multi_tbl_22 |
| 23 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | multi_db_multi_tbl_23 |
+ ------ + ------------------------------------------------------------------ + ----------------------- +
セットの24行 (0.01秒) 

論理テーブルのシャーディングルールを表示します。 ルールは、ハッシュがシャーディングに使用されることを示します。 データベースシャードキーはIDで、テーブルシャードキーはbidです。

mysql> multi_db_multi_tblからの表示ルール;
+ ------ -------------------- + --------- + ------------------ + --------------------- + -------------------- + ------------------ + --------------------- + -------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ -------------------- + --------- + ------------------ + --------------------- + -------------------- + ------------------ + --------------------- + -------------------- +
| 0 | multi_db_multi_tbl | 0 | id | ハッシュ | 8 | 入札 | ハッシュ | 3 |
+ ------ -------------------- + --------- + ------------------ + --------------------- + -------------------- + ------------------ + --------------------- + -------------------- +
1行セット (0.01秒) 

シャーディングにダブルフィールドを含むハッシュ関数を使用する

  • シャードキーは、文字データ型または数値データ型である必要があります。
  • ルーティング方法: シャードキーの最後のN文字を使用してハッシュ値を計算します。 次に、ハッシュ関数を使用してルートを計算します。 Nは、ハッシュ関数の第3のパラメータを指定する。 たとえば、RANGE_HASH(COL1, COL2, N) 関数を使用する場合、COL1が選択され、計算用の最後のN文字を取得するために切り捨てられます。 COL1が存在しない場合は、COL2を選択して計算する。
  • シナリオ: 2つのシャードキーが必要であり、1つのシャードキーの値のみがクエリに使用されます。 たとえば、8つの物理データベースがPolarDB-X 1.0インスタンスに割り当てられ、サービスには次のシナリオが必要です。
    • データベースシャーディングは、買い手IDおよび注文IDに基づいて注文テーブル上で実行される。
    • バイヤーIDまたは注文IDのみがクエリの条件として指定されます。

この場合、次のDDLステートメントを実行して注文テーブルを作成できます。

テーブルtest_order_tbを作成する (
 id bigint not null auto_increment,
 seller_id varchar(30) DEFAULT NULL、
 order_id varchar (30) DEFAULT NULL、
 buyer_id varchar (30) DEFAULT NULL、
 create_time datetime DEFAULT NULL、
 主キー (id)
ENGINE=InnoDB DEFAULT CHARSET=utf8 dbpartition by RANGE_HASH(buyer_id, order_id, 10) tbpartition by RANGE_HASH(buyer_id, order_id, 10) tbpartitions 3; 
説明
  • 2つのシャードキーは変更できません。
  • 2つのシャードキーが異なるデータベースシャードまたはテーブルシャードを指している場合、データの挿入に失敗します。

シャーディングに日付関数を使用する

シャーディングアルゴリズムとしてハッシュ関数を使用できます。 MMDDWEEKMMDDなどの日付関数をシャーディングアルゴリズムとして使用して、テーブルをシャードできます。 次の例は、シャーディングに日付関数を使用する方法を示しています。

データベースシャーディングとテーブルシャーディングの両方が実行されるテーブルを作成します。 テーブルは論理テーブルである。 データベースシャーディングは、userId列に基づいてハッシュを実装することによって実行されます。 テーブルシャーディングは、actionDate列に基づいてWEEK(actionDate) 日付関数を使用してDAY_OF_WEEKを計算します。 論理テーブル内のデータは、1週間の日数に基づいて7つの物理テーブルにルーティングされます。

たとえば、actionDate列の値が2017-02-27で、日が月曜日の場合、WEEK(actionDate) 関数から返される値は2です。 この場合、2017-02-27を含むデータレコードは、次の式に基づいて2に対応するテーブルシャードに格納されます。2% 7 = 2。 このテーブルシャードはデータベースシャードにあり、user_log_2という名前です。 actionDate列の値が2017-02-26で、日が日曜日の場合、WEEK(actionDate) 関数が返す値は1です。 この場合、2017-02-26を含むデータレコードは、次の式に基づいて1に対応するテーブルシャードに格納されます。1% 7 = 1。 このテーブルシャードはデータベースシャードにあり、user_log_1という名前です。

CREATE TABLE user_log (
 userId int, 
 名前varchar(30) 、 
 操作varchar(30) 、 
 actionDate日付
) dbpartition by hash(userId) tbpartition by WEEK(actionDate) tbpartitions 7; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、1週間の日数に基づいて、各データベースシャードに7つのテーブルシャードが作成されることを示しています。

mysql> user_logからトポロジを表示する。------ ------------------------------------------------------------------ -------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ -------------
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_0 |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_1 |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_2 |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_3 |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_4 |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_5 |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log_6 |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_0 |
| 8 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_1 |
| 9 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_2 |
| 10 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_3 |
| 11 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_4 |
| 12 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_5 |
| 13 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log_6 |
...
| 49 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_0 |
| 50 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_1 |
| 51 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_2 |
| 52 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_3 |
| 53 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_4 |
| 54 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_5 |
| 55 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log_6 |
------ ------------------------------------------------------------------ -------------
セットの56行 (0.01秒) 
説明 返される結果が長いため、一部のデータを省略するために省略記号 (…) が使用されます。

論理テーブルのシャーディングルールを表示します。 このルールは、データベースシャーディングメソッドがhashingであり、データベースシャードキーがuserIdであることを示しています。 このルールは、WEEK関数を使用してテーブルをシャードし、テーブルシャードキーがactionDateであることも示しています。

mysql> user_logからの表示ルール;
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| 0 | user_log | 0 | userId | ハッシュ | 8 | actionDate | 週 | 7 |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
1行セット (0.00秒) 

この方法では、データベースシャードキーとテーブルシャードキーを指定すると、物理データベースシャードと、SQLステートメントがルーティングされる物理データベースシャードに属する物理テーブルを表示できます。

データベースシャーディングとテーブルシャーディングの両方が実行されるテーブルを作成します。 テーブルは論理テーブルである。 データベースシャーディングは、userId列に基づいてハッシュを実行することによって実行されます。 テーブルシャーディングは、actionDate列に基づいてMM(actionDate) 日付関数を使用してMONTH_OF_YEARを計算します。 論理テーブル内のデータは、1年の月数に基づいて12の物理テーブルにルーティングされます。

たとえば、actionDate列の値が2017-02-27の場合、MM(actionDate) 関数が返す値は02です。 この場合、2017-02-27を含むデータレコードは、次の式に基づいて02に対応するテーブルシャードに格納されます。02% 12 = 02。 このテーブルシャードはデータベースシャードにあり、user_log_02という名前です。 actionDate列の値が2016-12-27の場合、MM(actionDate) 関数が返す値は12です。 この場合、2016-12-27を含むデータレコードは、次の式に基づいて00に対応するテーブルシャードに格納されます。12% 12 = 00。 このテーブルシャードはデータベースシャードにあり、user_log_00という名前です。

CREATE TABLE user_log2 (
 userId int, 
 名前varchar(30) 、 
 操作varchar(30) 、 
 actionDate日付
) dbpartition by hash(userId) tbpartition by MM(actionDate) tbpartitions 12; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、1年の月数に基づいて、各データベースシャードに12のテーブルシャードが作成されることを示しています。

mysql> user_log2からトポロジを表示します。------ ------------------------------------------------------------------ ----------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ ----------------
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_00 |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_01 |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_02 |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_03 |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_04 |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_05 |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_06 |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_07 |
| 8 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_08 |
| 9 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_09 |
| 10 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_10 |
| 11 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log2_11 |
| 12 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_00 |
| 13 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_01 |
| 14 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_02 |
| 15 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_03 |
| 16 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_04 |
| 17 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_05 |
| 18 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_06 |
| 19 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_07 |
| 20 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_08 |
| 21 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_09 |
| 22 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_10 |
| 23 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0001_RDS | user_log2_11 |
...
| 84 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_00 |
| 85 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_01 |
| 86 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_02 |
| 87 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_03 |
| 88 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_04 |
| 89 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_05 |
| 90 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_06 |
| 91 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_07 |
| 92 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_08 |
| 93 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_09 |
| 94 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_10 |
| 95 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log2_11 |
------ ------------------------------------------------------------------ ----------------
セットの96行 (0.02秒) 
説明 返される結果が長いため、一部のデータを省略するために省略記号 (…) が使用されます。

論理テーブルのシャーディングルールを表示します。 このルールは、データベースシャーディングメソッドがhashingであり、データベースシャードキーがuserIdであることを示しています。 このルールは、MM date関数を使用してテーブルをシャードし、テーブルシャーディングキーがactionDateであることも示しています。

mysql> user_log2からルールを表示します。+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| 0 | user_log2 | 0 | userId | ハッシュ | 8 | actionDate | mm | 12 |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
1行セット (0.00秒) 

データベースシャーディングとテーブルシャーディングの両方が実行されるテーブルを作成します。 テーブルは論理テーブルである。 データベースシャーディングは、userId列に基づいてハッシュを実装することによって実行されます。 DD(actionDate) 関数を使用してテーブルシャーディングを実行し、DAY_OF_MONTHを計算します。 論理テーブル内のデータは、1か月の最大日数に基づいて31の物理テーブルにルーティングされます。

たとえば、actionDate列の値が2017-02-27の場合、DD(actionDate) 関数から返される値は27です。 この場合、2017-02-27を含むデータレコードは、次の式に基づいて27に対応するテーブルシャードに格納されます。27% 31 = 27。 このテーブルシャードはデータベースシャードにあり、user_log_27という名前です。

CREATE TABLE user_log3 (
 userId int, 
 名前varchar(30) 、 
 操作varchar(30) 、 
 actionDate日付
) dbpartition by hash(userId) tbpartition by DD(actionDate) tbpartitions 31; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、1か月の最大日数に基づいて、各データベースシャードに31のテーブルシャードが作成されていることを示しています。

mysql> user_log3からトポロジを表示します。------ ------------------------------------------------------------------ ----------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ ----------------
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_00 |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_01 |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_02 |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_03 |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_04 |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_05 |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_06 |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_07 |
| 8 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_08 |
| 9 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_09 |
| 10 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_10 |
| 11 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_11 |
| 12 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_12 |
| 13 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_13 |
| 14 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_14 |
| 15 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_15 |
| 16 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_16 |
| 17 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_17 |
| 18 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_18 |
| 19 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_19 |
| 20 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_20 |
| 21 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_21 |
| 22 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_22 |
| 23 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_23 |
| 24 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_24 |
| 25 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_25 |
| 26 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_26 |
| 27 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_27 |
| 28 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_28 |
| 29 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_29 |
| 30 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log3_30 |
...
| 237 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_20 |
| 238 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_21 |
| 239 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_22 |
| 240 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_23 |
| 241 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_24 |
| 242 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_25 |
| 243 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_26 |
| 244 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_27 |
| 245 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_28 |
| 246 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_29 |
| 247 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log3_30 |
------ ------------------------------------------------------------------ ----------------
セット内の248行 (0.01秒) 
説明 返される結果が長いため、一部のデータを省略するために省略記号 (…) が使用されます。

論理テーブルのシャーディングルールを表示します。 このルールは、データベースシャーディングメソッドがhashingであり、データベースシャードキーがuserIdであることを示しています。 このルールは、DD date関数を使用してテーブルをシャードし、テーブルシャードキーがactionDateであることも示しています。

mysql> user_log3からルールを表示します。+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| 0 | user_log3 | 0 | userId | ハッシュ | 8 | actionDate | dd | 31 |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
1行セット (0.01秒) 

データベースシャーディングとテーブルシャーディングの両方が実行されるテーブルを作成します。 テーブルは論理テーブルである。 データベースシャーディングは、userId列に基づいてハッシュを実装することによって実行されます。 テーブルシャーディングは、MMDD(actionDate) tbpartitions 365関数を使用して実行し、DAY_OF_YEAR % 365を計算します。 論理テーブル内のデータは、年としてカウントされる365日に基づいて365の物理テーブルにルーティングされます。

たとえば、actionDate列の値が2017-02-27の場合、MMDD(actionDate) 関数から返される値は58です。 この場合、2017-02-27を含むデータレコードは、58に対応するテーブルシャードに格納されます。 このテーブルシャードはデータベースシャードにあり、user_log_58という名前です。

CREATE TABLE user_log4 (
 userId int, 
 名前varchar(30) 、 
 操作varchar(30) 、 
 actionDate日付
) dbpartition by hash(userId) tbpartition by MMDD(actionDate) tbpartitions 365; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、年としてカウントされる365日に基づいて、各データベースシャードに365テーブルシャードが作成されることを示しています。

mysql> user_log4からトポロジを表示します。------ ------------------------------------------------------------------ -----------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ -----------------
...
| 2896 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_341 |
| 2897 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_342 |
| 2898 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_343 |
| 2899 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_344 |
| 2900 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_345 |
| 2901 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_346 |
| 2902 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_347 |
| 2903 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_348 |
| 2904 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_349 |
| 2905 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_350 |
| 2906 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_351 |
| 2907 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_352 |
| 2908 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_353 |
| 2909 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_354 |
| 2910 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_355 |
| 2911 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_356 |
| 2912 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_357 |
| 2913 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_358 |
| 2914 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_359 |
| 2915 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_360 |
| 2916 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_361 |
| 2917 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_362 |
| 2918 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_363 |
| 2919 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log4_364 |
------ ------------------------------------------------------------------ -----------------
セット内の2920行 (0.07秒) 
説明 返される結果が長いため、一部のデータを省略するために省略記号 (…) が使用されます。

論理テーブルのシャーディングルールを表示します。 このルールは、データベースシャーディングメソッドがhashingであり、データベースシャードキーがuserIdであることを示しています。 このルールは、MMDD date関数を使用してテーブルをシャードし、テーブルシャーディングキーがactionDateであることも示しています。

mysql> user_log4からルールを表示します。+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| 0 | user_log4 | 0 | userId | ハッシュ | 8 | actionDate | mmdd | 365 |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
1行セット (0.02秒) 

データベースシャーディングとテーブルシャーディングの両方が実行されるテーブルを作成します。 テーブルは論理テーブルである。 データベースシャーディングは、userId列に基づいてハッシュを実装することによって実行されます。 MMDD(actionDate) tbpartitions 10を使用してテーブルシャーディングを実行し、DAY_OF_YEAR % 10を計算します。 論理テーブルは365日を1年として使用してシャードされ、論理テーブル内のデータは10個の物理テーブルにルーティングされます。

CREATE TABLE user_log5 (
 userId int, 
 名前varchar(30) 、 
 操作varchar(30) 、 
 actionDate日付
) dbpartition by hash(userId) tbpartition by MMDD(actionDate) tbpartitions 10; 

論理テーブルのノードトポロジを表示します。 ノードトポロジは、各データベースシャードに10個のテーブルシャードが作成されていることを示しています。 論理テーブルは365日を1年として使用してシャードされ、論理テーブル内のデータは10個の物理テーブルにルーティングされます。

mysql> user_log5からトポロジを表示します。------ ------------------------------------------------------------------ ----------------
| ID | GROUP_NAME | テーブル名 |
------ ------------------------------------------------------------------ ----------------
| 0 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_00 |
| 1 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_01 |
| 2 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_02 |
| 3 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_03 |
| 4 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_04 |
| 5 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_05 |
| 6 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_06 |
| 7 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_07 |
| 8 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_08 |
| 9 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0000_RDS | user_log5_09 |
...
| 70 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_00 |
| 71 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_01 |
| 72 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_02 |
| 73 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_03 |
| 74 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_04 |
| 75 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_05 |
| 76 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_06 |
| 77 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_07 |
| 78 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_08 |
| 79 | SANGUAN_TEST_123_1488766060743ACTJSANGUAN_TEST_123_WVVP_0007_RDS | user_log5_09 |
------ ------------------------------------------------------------------ ----------------
セットの80行 (0.02秒) 
説明 返される結果が長いため、一部のデータを省略するために省略記号 (…) が使用されます。

論理テーブルのシャーディングルールを表示します。 このルールは、データベースシャーディングメソッドがhashingであり、データベースシャードキーがuserIdであることを示しています。 このルールでは、actionDateシャードキーに基づいてMMDD date関数を使用してテーブルがシャードされ、テーブルデータが10個の物理テーブルにルーティングされることも示されています。

mysql> user_log5からルールを表示します。+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| ID | テーブル名 | 放送 | DB_PARTITION_KEY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_POLICY | TB_PARTITION_COUNT |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
| 0 | user_log5 | 0 | userId | ハッシュ | 8 | actionDate | mmdd | 10 |
+ ------ ---------- ---------------- ------------------ + --------------------- + --------------------- + -------------------- + --------------------- +
1行セット (0.01秒) 

主キーをシャードキーとして使用する

シャーディングアルゴリズムにシャードキーを指定しない場合、システムはデフォルトで主キーをシャードフィールドとして使用します。 次のコードでは、主キーをデータベースシャードキーおよびテーブルシャードキーとして使用する方法の例を示します。

  • プライマリキーをデータベースシャードキー
    として使用するCREATE TABLE prmkey_tbl (
     id bigint not null auto_increment, 
     名前varchar(30) 、 
     主キー (id)
    ) dbpartition by hash(); 
  • プライマリキーをシャードキー
    として使用するCREATE TABLE prmkey_multi_tbl (
     id bigint not null auto_increment, 
     名前varchar(30) 、 
     主キー (id)
    ) dbpartition by hash() tbpartition by hash() tbpartitions 3; 

MySQL CREATE TABLEステートメントのその他の属性

MySQL CREATE TABLEステートメントを実行してテーブルを作成するときに、シャーディングメソッドとテーブルのその他の属性を指定できます。 次のサンプルコードは、他の属性を指定する方法の例を示します。

CREATE TABLE multi_db_multi_tbl (
  id bigint not null auto_increment, 
  名前varchar(30) 、 
  主キー (id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 dbpartition by hash(id) tbpartition by hash(id) tbpartitions 3; 

GSI

このセクションでは、テーブルを作成するときにGSIを定義する方法について説明します。

説明 次の例では、作成された8つのデータベースシャードが使用されています。

GSIの定義

CREATE TAB_order (
 'id' bigint(11) NOT NULL AUTO_INCREMENT、
 'order_id' varchar(20) DEFAULT NULL、
 'buyer_id 'varchar(20) デフォルトNULL、
 'seller_id 'varchar(20) DEFAULT NULL、
 'order_snapshot' ロングテキストDEFAULT NULL、
 'order_detail' ロングテキストDEFAULT NULL、
 主要なキー ('id') 、
 グローバルインデックス 'g_i_seller '('seller_id') dbpartition by hash('seller_id')
) ENGINE=InnoDB DEFAULT CHARSET=ハッシュによるutf8 dbpartition ('order_id'); 

次のパラメータに注意してください。

  • t_order: テーブルシャーディングの代わりにデータベースシャーディングが実行されるプライマリテーブル。 データベースシャーディングは、order_id列に基づくハッシュを使用して実行されます。
  • g_i_seller: テーブルシャーディングの代わりにデータベースシャーディングが実行されるインデックステーブル。 データベースシャーディングは、seller_id列に基づくハッシュを使用して実行されます。 カバーコラムは指定されません。
  • GLOBAL INDEX 'g_i_seller '('seller_id') dbpartition by hash('seller_id'): GSIを定義するために使用される句。

SHOW INDEXステートメントを実行して、order_idシャードキーのローカルセカンダリインデックスやseller_ididorder_idのGSIなどのインデックス情報を表示します。 seller_idはインデックステーブルのシャードキーで、idorder_idはデフォルトのカバー列です。 デフォルトのカバー列には、プライマリテーブルのプライマリキー列とシャードキー列が含まれます。

mysql> t_orderからインデックスを表示します。---------------- ------------------------- -------------------------------------------------------------------------------
| テーブル | NON_UNIQUE | KEY_NAME | SEQ_IN_INDEX | COLUMN_NAME | COLLATION | CARDINALITY | SUB_PART | PACKED | NULL | INDEX_TYPE | COMMENT | INDEX_COMMENT |
---------------- ------------------------- -------------------------------------------------------------------------------
| t_order | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | |
| t_order | 1 | auto_shard_key_order_id | 1 | order_id | A | 0 | NULL | NULL | YES | BTREE | |
| t_order | 1 | g_i_seller | 1 | seller_id | NULL | 0 | NULL | NULL | YES | グローバル | インデックス | |
| t_order | 1 | g_i_seller | 2 | id | NULL | 0 | NULL | NULL | | グローバル | カバー | |
| t_order | 1 | g_i_seller | 3 | order_id | NULL | 0 | NULL | NULL | YES | グローバル | カバー | |
---------------- ------------------------- ----------------------------------------------------------------------------------------------------------------

SHOW GLOBAL INDEXステートメントを実行して、GSIに関する情報を照会できます。 詳細については、「」をご参照ください。

グローバルインデックスを表示します。

mysql> t_orderからグローバルインデックスを表示します。------- --------- ------------ --------------------------------- ---------------- --------------- + ---------------- + --------------------- + --------------------- +
| スキーマ | テーブル | NON_UNIQUE | KEY_NAME | INDEX_NAMES | COVERING_NAMES | INDEX_TYPE | DB_PARTITION_POLICY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_COUNTIUS
------- --------- ------------ --------------------------------- ---------------- --------------- + ---------------- + --------------------- + --------------------- +
| d7 | t_order | 1 | g_i_seller | id, order_id | NULL | seller_id | HASH | 8 | | NULL | NULL | NULL | PUBLIC |
------- --------- ------------- -------------------------------- ---------------- --------------- ------------------ + --------------------- + --------------------- + -------------------- + -------------------- + -------------------- + -------------------- +---------- 

インデックステーブルのスキーマを表示します。 インデックステーブルには、プライマリテーブルのプライマリキー、シャードキー、および既定のカバーリング列が含まれます。 プライマリキー列にはAUTO_INCREMENT属性が含まれておらず、プライマリテーブルにはローカルのセカンダリインデックスが含まれていません。

mysql> show create table g_i_seller;
+ ------------ + ----------------------------------------------------------- +
| テーブル | テーブルの作成 |
+ ------------ + ----------------------------------------------------------- +
| g_i_seller | CREATE TABLE 'g_i_seller '(
 'id' bigint(11) NOT NULL、
 'order_id' varchar(20) DEFAULT NULL、
 'seller_id 'varchar(20) DEFAULT NULL、
 主要なキー ('id') 、
 KEY 'auto_shard_key_seller_id ' ('seller_id') BTREEを使用
) ENGINE=InnoDB DEFAULT CHARSET=ハッシュによるutf8 dbpartition ('seller_id') |
+ ------------ + ----------------------------------------------------------- + 

ユニークなGSIを定義する

CREATE TAB_order (
 'id' bigint(11) NOT NULL AUTO_INCREMENT、
 'order_id' varchar(20) DEFAULT NULL、
 'buyer_id 'varchar(20) デフォルトNULL、
 'seller_id 'varchar(20) DEFAULT NULL、
 'order_snapshot' ロングテキストDEFAULT NULL、
 'order_detail' ロングテキストDEFAULT NULL、
 主要なキー ('id') 、
 ユニークなグローバルインデックス 'g_i_buyer '('buyer_id') COVERING('seller_id' 、'order_snapshot') 
   tbpartition by hash('buyer_id') tbpartition by hash('buyer_id') tbpartitions 3
) ENGINE=InnoDB DEFAULT CHARSET=ハッシュによるutf8 dbpartition ('order_id'); 

次のパラメータに注意してください。

  • t_order: テーブルシャーディングの代わりにデータベースシャーディングが実行されるプライマリテーブル。 データベースシャーディングは、order_id列に基づくハッシュを使用して実行されます。
  • g_i_buyer: データベースシャーディングとテーブルシャーディングが実行されるインデックステーブル。 テーブルシャーディングとデータベースシャーディングは、buyer_id列に基づくハッシュを使用して実行されます。 対象となる列には、seller_id列とorder_snapshot列があります。
  • UNIQUE GLOBAL INDEX 'g_i_buyer '('buyer_id') COVERING('seller_id', 'order_snapshot') dbpartition by hash('buyer_id') tbpartition by hash('buyer_id') tbpartitions 3: 一意のGSIを定義するために使用される句。

SHOW INDEXステートメントを実行して、order_idシャードキーのローカルセカンダリインデックスに関する情報や、buyer_ididorder_idseller_idorder_snapshotの一意のGSIなどのインデックス情報を表示します。 buyer_idはインデックステーブルのシャードキーで、idorder_idはデフォルトのカバー列です。 デフォルトのカバー列には、プライマリテーブルのプライマリキー列とシャードキー列が含まれます。 seller_idorder_snapshotは、一意のGSIが定義されたときに指定されるカバー列です。

mysql> t_orderからインデックスを表示します。--------------------- ------------------------- ---------------------------------------------------------------------------- --
| テーブル | NON_UNIQUE | KEY_NAME | SEQ_IN_INDEX | COLUMN_NAME | COLLATION | CARDINALITY | SUB_PART | PACKED | NULL | INDEX_TYPE | COMMENT | INDEX_COMMENT |
--------------------- ------------------------- ---------------------------------------------------------------------------- --
| t_order_dthb | 0 | PRIMARY | 1 | id | A | 0 | NULL | NULL | | BTREE | |
| t_order_dthb | 1 | auto_shard_key_order_id | 1 | order_id | A | 0 | NULL | NULL | YES | BTREE | |
| t_order | 0 | g_i_buyer | 1 | buyer_id | NULL | 0 | NULL | NULL | YES | グローバル | インデックス | |
| t_order | 1 | g_i_buyer | 2 | id | NULL | 0 | NULL | NULL | | グローバル | カバー | |
| t_order | 1 | g_i_buyer | 3 | order_id | NULL | 0 | NULL | NULL | YES | グローバル | カバー | |
| t_order | 1 | g_i_buyer | 4 | seller_id | NULL | 0 | NULL | NULL | YES | グローバル | カバー | |
| t_order | 1 | g_i_buyer | 5 | order_snapshot | NULL | 0 | NULL | NULL | YES | グローバル | カバー | |
--------------------- ------------------------- -----------------------------------------------------------------------------------------------------------

SHOW GLOBAL INDEXステートメントを実行して、GSIに関する情報を照会できます。 詳細については、「」をご参照ください。

グローバルインデックスを表示します。

mysql> t_orderからグローバルインデックスを表示します。------- --------- ------------- ----------------------------- ----------------------------------------- -------------- ------------------ + --------------------- + -------------------- + -------------------- +
| スキーマ | テーブル | NON_UNIQUE | KEY_NAME | INDEX_NAMES | COVERING_NAMES | INDEX_TYPE | DB_PARTITION_POLICY | DB_PARTITION_POLICY | DB_PARTITION_COUNT | TB_PARTITION_KEY | TB_PARTITION_COUNTIUS
------- --------- ------------- ----------------------------- ----------------------------------------- -------------- ------------------ + --------------------- + -------------------- + -------------------- +
| d7 | t_order | 0 | g_i_buyer | buyer_id | id、order_id、seller_id、order_snapshot | NULL | buyer_id | HASH | 8 | buyer_id | HASH | 3 | PUBLIC |
------- --------- -------------------------------------------- ----------------------------------------- --------------- ------------------ + --------------------- + -------------------- + -------------------- + -------------------- + -------------------- + -------------------- +----------- 

インデックステーブルのスキーマを表示します。 インデックステーブルには、プライマリテーブルのプライマリキー、シャードキー、既定のカバーリング列、および一意のGSIが定義されたときに指定されるカバーリング列が含まれます。 プライマリキー列にはAUTO_INCREMENT属性が含まれておらず、プライマリテーブルにはローカルのセカンダリインデックスが含まれていません。 デフォルトでは、一意のGSI用にテーブルが作成されます。 このように、一意のGSIに対応するデータは一意である。

mysql> show create table g_i_buyer;
+ ----------- + -------------------------------------------------------------------------------------------------------- +
| テーブル | テーブルの作成 |
+ ----------- + -------------------------------------------------------------------------------------------------------- +
| g_i_buyer | CREATE TABLE 'g_i_buyer '(
  'id' bigint(11) NOT NULL、
  'order_id' varchar(20) DEFAULT NULL、
  'buyer_id 'varchar(20) デフォルトNULL、
  'seller_id 'varchar(20) DEFAULT NULL、
  'order_snapshot' ロングテキスト、
  主要なキー ('id') 、
  ユニークなキー 'auto_shard_key_buyer_id ' ('buyer_id') BTREEを使用
エンジン=InnoDB DEFAULT CHARSET=utf8 dbpartition by hash('buyer_id ') tbpartition by hash('buyer_id') tbpartition 3 |
+ ----------- + -------------------------------------------------------------------------------------------------------- +