PolarDB:CREATE TABLE (DRDSモード)

構文

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] ...

# グローバルセカンダリインデックスに関連する節
global_secondary_index_option:
    [COVERING (col_name,...)]
    [drds_partition_options]
    [VISIBLE | INVISIBLE]

# データベースとテーブルのシャーディングを実装するために使用できる句
drds_partition_options:
    db_partition_algorithmによるDBPARTITION
    [TBPARTITION BY table_partition_algorithm [TBPARTITIONS num]]
    [LOCALITY=locality_option]

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)

# テーブルを作成するときに、非シャードテーブルの格納場所を指定するために使用できる句
locality_option:
    'dn=storage_inst_id_list'

storage_inst_id_list:
    storage_inst_id[,storage_inst_id_list]
    
# 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 | ハッシュ} 

データベースとテーブルシャーディングを実装するための条項とパラメータ

• DBPARTITION BY hash(partition_key): データベースシャードキーとハッシュベースのデータベースシャーディングアルゴリズムを指定します。

• TBPARTITION BY { HASH (列) | {MM | DD | WEEK | MMDD | YYYYMM | YYYYWEEK | YYYYMM_OPT | YYYYYYWEEK_OPT | YYYYDD_OPT}(列): オプション。 この句は、テーブルシャーディング方法を指定します。 デフォルトでは、この句はDBPARTITION By句と同じように機能します。

• TBPARTITIONS num: オプション。 この句は、各データベースシャード内の物理テーブルの数を指定します。 このパラメーターのデフォルト値は1です。 テーブルシャーディングが不要な場合は、このパラメーターを設定する必要はありません。

• シャーディング関数の詳細については、「シャーディング関数」をご参照ください。

GSIを定義するための条項とパラメータ

• [UNIQUE] GLOBAL: インデックスがグローバルセカンダリインデックス (GSI) であることを指定します。 UNIQUE GLOBALは、インデックスが一意のGSIであることを指定します。

• index_name: インデックスの名前を指定します。 インデックステーブルは同じ名前を使用します。

• index_type: インデックステーブルのシャードキーのローカルインデックスのタイプを指定します。 サポートされているローカルインデックスの種類については、MySQLドキュメントをご参照ください。

• index_sharding_col_name,...: インデックス列を指定します。 インデックス列には、インデックステーブルのすべてのシャードキー列が含まれ、他の列は含まれません。 詳細については、「グローバルセカンダリインデックスの使用方法」をご参照ください。

• global_secondary_index_option: PolarDB-X GSIの拡張構文を指定します。

  • COVERING (col_name,...): カバーする列を指定します。 カバー列は、インデックス列を除くインデックステーブルのすべての列を含む。 デフォルトでは、カバー列にはベーステーブルの主キー列とシャードキー列が含まれます。 詳細については、「グローバルセカンダリインデックスの使用方法」をご参照ください。

  • drds_partition_options: インデックステーブルに1つ以上のシャーディング句を指定します。 詳細については、このトピックの「データベースとテーブルシャーディングを実装するための節とパラメーター」を参照してください。

• index_option: インデックステーブルのシャードキーのローカルインデックスの属性を指定します。 詳細については、「MySQLドキュメント」をご参照ください。

エンドツーエンドのストレステスト用のShadow table句

SHADOW: エンドツーエンドのストレステスト用のシャドウテーブルを作成します。 テーブル名は、プレフィックスとして _test_ を使用する必要があります。 プレフィックスの後のテーブル名は、関連付けられた仮テーブル名と同じである必要があり、仮テーブルはシャドウテーブルの前に作成する必要があります。

ロカリティ

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

非シャードテーブルを作成します。 テーブルは論理テーブルである。

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

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

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

CREATE TABLE tb1 (id int) LOCALITY='dn=polardbx-storage-0-master ';

ショーTOPOLOGYからtb1;

+----+------------------+------------+.
| ID | GROUP_NAME | テーブル名 |
+ ---- + ------------------ -----------
| 0 | DB1_000000_GROUP | tb1 |
+ ---- + ------------------ -----------
1行のセット 

データベースシャーディングを使用してテーブルを作成し、テーブルデータを配布する

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

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

論理テーブルのノードトポロジを表示します。 この例では、トポロジは、8つのデータベースシャードのそれぞれに1つのテーブルシャードが作成されることを示しています。 テーブルシャードはそれ以上シャードされません。

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秒) 

データベースシャーディングとテーブルシャーディングを使用してテーブルを作成し、テーブルデータを配布する

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

• シャーディングにはハッシュ関数を使用します。

• シャーディング用のダブルフィールドを含むハッシュ関数を使用します。

• シャーディングに日付関数を使用します。

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

データベースシャーディングとテーブルシャーディングを使用して、テーブルを作成し、テーブルデータを配布します。 ID列でハッシュ関数を使用して8つのデータベースシャードにデータを分散し、ハッシュ関数を使用して、入札列に基づいて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つのテーブルシャードが作成されていることを示しています。

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列に基づくハッシュ関数を使用してデータベースシャーディングを実装し、入札列に基づくハッシュ関数を使用してテーブルシャーディングを実装します。

ショールールから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秒) 

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

• シャードキーは、文字または数値データ型である必要があります。

• ルーティング方法: 1つのシャードキーの最後のN文字に基づいてハッシュ値を計算し、データが格納される特定のシャードを決定します。 Nは、ハッシュ関数の第3のパラメータを指定する。 たとえば、RANGE_HASH(COL1, COL2, N) 関数を使用する場合、COL1が選択され、計算用の最後のN文字を取得するために切り捨てられます。 COL1が存在しない場合は、COL2を選択して計算する。

• シナリオ: データベースシャーディングには2つのシャードキーが必要であり、1つのシャードキーに基づいてクエリを正しく指定できます。 たとえば、PolarDB-Xデータベースには8つの物理データベースシャードがあります。

  • データベースは、購入者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; 

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

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

データベースシャーディングとテーブルシャーディングを使用して、テーブルを作成し、テーブルデータを配布します。 userId列のハッシュ値に基づいてデータベースシャーディングを実装します。 WEEK(actionDate) 関数を使用して、actionDate列から計算されたDAY_OF_WEEK値に基づいて各データベースシャードにテーブルシャーディングを実装し、テーブルデータを7つの物理テーブルに分散します。

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

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

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秒) 

論理テーブルのシャーディングルールを照会します。 この例では、ルールはデータベースシャードキーuserIdに基づくハッシュ関数を使用してデータベースシャーディングを実装し、テーブルシャードキーactionDateに基づくWEEK日付関数を使用してテーブルシャーディングを実装します。

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列のハッシュ値に基づいてデータベースシャーディングを実装します。 MM(actionDate) date関数を使用して、actionDate列から計算されたMONTH_OF_YEAR値に基づいて各データベースシャードにテーブルシャーディングを実装し、テーブルデータを12の物理テーブルに分散します。

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

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秒) 

論理テーブルのシャーディングルールを照会します。 この例では、ルールはデータベースシャードキーuserIdに基づくハッシュ関数を使用してデータベースシャーディングを実装し、テーブルシャードキーactionDateに基づくMM date関数を使用してテーブルシャーディングを実装します。

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値に基づいて各データベースシャードにテーブルシャーディングを実装し、テーブルデータを31の物理テーブルに分散します。

たとえば、actionDate列の値が2017-02-27の場合、DD(actionDate) 関数によって返される値は27です。 この場合、2017-02-27を含むデータレコードは、次の式に基づいて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個のテーブルシャードが作成されます。

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秒) 

論理テーブルのシャーディングルールを照会します。 この例では、ルールはデータベースシャードキーuserIdに基づくハッシュ関数を使用してデータベースシャーディングを実装し、テーブルシャードキーactionDateに基づくDD date関数を使用してテーブルシャーディングを実装します。

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 date関数を使用して計算されたDAY_OF_YEAR % 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; 

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

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秒) 

論理テーブルのシャーディングルールを照会します。 この例では、ルールはデータベースシャードキーuserIdに基づくハッシュ関数を使用してデータベースシャーディングを実装し、テーブルシャードキーactionDateに基づくMMDD date関数を使用してテーブルシャーディングを実装します。

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 date関数を使用して計算されたDAY_OF_YEAR % 10値に基づいて各データベースシャードにテーブルシャーディングを実装し、テーブルデータを10個の物理テーブルに分散します。

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

論理テーブルのノードトポロジを照会します。 この例では、ノードトポロジは、各データベースシャードに10個のテーブルシャードが作成されていることを示しています。 論理テーブルは、1年の日数 (365日) に基づいて、各データベースシャード内の10個の物理テーブルにシャードされます。

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秒) 

論理テーブルのシャーディングルールを照会します。 この例では、ルールはデータベースシャードキーuserIdに基づくハッシュ関数を使用してデータベースシャーディングを実装し、MMDD date関数を使用してactionDateキーに基づくテーブルシャーディングを実装し、テーブルデータを各データベースシャード内の10個の物理テーブルにルーティングします。

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秒) 

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の定義

例

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_id、id、およびorder_id列のGSIに関する情報を照会できます。 seller_idはインデックステーブルのシャードキーで、idとorder_idはデフォルトのカバー列です。 デフォルトのカバー列には、ベーステーブルの主キー列とシャードキー列が含まれます。

は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に関する情報を照会できます。 詳細については、「グローバルインデックスを表示」をご参照ください。

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属性がなく、ベーステーブルにはローカルインデックスがありません。

showテーブルを作成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_id、id、order_id、seller_id、およびorder_snapshot列の一意のGSIをクエリできます。 buyer_idはインデックステーブルのシャードキーで、idとorder_idはデフォルトのカバー列です。 デフォルトのカバー列には、ベーステーブルの主キー列とシャードキー列が含まれます。 seller_idとorder_snapshotは、一意のGSIが定義されたときに指定されるカバー列です。

は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に関する情報を照会できます。 詳細については、「グローバルインデックスを表示」をご参照ください。

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用のテーブルが作成され、インデックス付き列の値がデータベース全体で一意になるようにします。

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 |
+ ----------- + -------------------------------------------------------------------------------------------------------- +