テーブルの作成

本記事では、SQLステートメントを使用してテーブルを作成する方法について説明します。また、テーブル作成の前提条件、テーブルの概要、遵守すべき要件などを紹介し、いくつかの例も示します。

テーブルの概要

テーブルは、一連の二次元配列の集合であり、データオブジェクト間の関係を表現し、データを格納するために使用されます。データベーステーブルを適切に設計し、活用することで、データの信頼性、整合性、およびクエリ性能を向上させ、データベース内のデータを効果的に管理し、活用することができます。

OceanBaseデータベースのテーブルに関する詳細情報については、テーブルの概要を参照してください。

前提条件

テーブルを作成する前に、以下の事項を確認してください：

• OceanBaseクラスタをデプロイし、MySQLモードのテナントを作成していること。OceanBaseクラスタのデプロイに関する詳細は、デプロイの概要を参照してください。

• OceanBaseデータベースのMySQLテナントに接続していること。データベースへの接続に関する詳細は、接続方法の概要を参照してください。

• データベースを作成していること。データベースの作成に関する詳細は、データベースの作成を参照してください。

• CREATE権限を持っていること。現在のユーザー権限を確認する操作については、ユーザー権限の確認を参照してください。この権限がない場合は、管理者に連絡し権限の付与を依頼してください。ユーザー権限の付与に関する操作については、直接権限の付与を参照してください。

コマンドラインでテーブルを作成する

CREATE TABLE ステートメントを使用してテーブルを作成してください。

テーブル名の定義

テーブルを作成する際には、まずテーブル名を付ける必要があります。テーブル名を定義する際に従うべき要件は以下のとおりです：

• OceanBaseデータベースのMySQLモードでは、各テーブル名はデータベース内で一意である必要があります。

• テーブル名は64文字を超えてはなりません。

• テーブルには意味のある名前を付けることを推奨します。t1やtable1などの名前は使用しないでください。その他のテーブル名の命名規則については、テーブル名の命名規則を参照してください。

例1：注文情報に関するテーブルを作成します。

CREATE TABLE orders (...);

列の定義

データベースにおいて、列（Column）はテーブル上の特定の属性のフィールド値を記録するために使用されます。ユーザーが各属性に付けた名前が列名となります。列名に加えて、列にはデータ型やデータ型の最大長（精度）などの情報も含まれます。

テーブルの列を定義する際に従うべき要件は以下のとおりです：

• データ型の特性に基づき、列に格納するデータに適切なデータ型を選択します。

  OceanBaseデータベースのMySQLモードでサポートされているデータ型と詳細については、データ型の概要を参照してください。

• 文字列データについては、可変長文字列データ型を使用し、最大長を指定することを推奨します。指定した最大長が格納する必要がある最大文字数よりも大きいことを確認し、最大長を超えた場合に文字が切り捨てられるのを防いでください。

• 主キー列の要件に基づき、テーブルに主キー列を定義する必要があるかどうかを確認します。

• その他の制約の要件に基づき、列に他の制約を追加する必要があるかどうかを確認します。

• 列にNOT NULL制約がある場合、通常はその列にデフォルト値を設定することを推奨します。列の型が日付または時刻型の場合、デフォルト値をデータベースの現在時刻に設定できます。

主キー列の定義

主キー値ルール（Primary Key Value Rule）は、特定のキー(Key、キーとは1列または複数列の集合を指す)に定義されるルールであり、テーブル内の各行データが特定のキー値によって一意に決定されることを保証します。各データベーステーブルでは、最大1つのPRIMARY KEY制約を定義できます。この制約を構成する列(1列または複数列)の値は、1行のデータを一意に識別するための識別子として機能し、すなわち各行データはその主キー値によって名付けることができます。

特定の列を主キー列として指定するには、その列の定義後にPRIMARY KEYキーワードを追加します。複数列に主キー制約を定義する場合は、CREATE TABLEステートメント内のすべての列のリストの後に、主キー制約の定義を追加します。

主キー列を定義する際には、以下の要件に従う必要があります：

• テーブルに主キーを定義することを推奨します。各データベーステーブルは、最大1つの主キー列の集合を持ちます。

  OceanBaseデータベースでは、ユーザーによるテーブルの主キー定義は必須ではありませんが、主キーを使用することで、テーブル内の各行データを一意に決定でき、重複するデータ行が存在しなくなります。適切なフィールドが主キーとして使用できない場合は、テーブル作成時に主キーを指定しなくても、テーブル作成後にシステムが自動インクリメント列を隠れた主キーとして指定します。自動インクリメント列の詳細については、自動インクリメント列の定義を参照してください。

  また、作成時に主キー列を定義しなかった場合でも、OceanBaseデータベースは既存のテーブルに主キー列を追加することをサポートしています。

• 主キー列の集合の値は、テーブル全体で一意である必要があります。

• 主キー列の数は64列を超えてはならず、主キーデータの総長は16KBを超えてはなりません。

• 主キー列の値はNULLまたは空文字列にすることはできません。主キー列には値を入力する必要があります。

• 主キー制約の名前を明示的に指定することを推奨します。例えば、主キー制約の名前を「PK_xxx」とします。

主キー制約に関する詳細は、主キー制約を参照してください。

例2：複数列に主キー制約を定義します。

obclient> CREATE TABLE test(c1 INT, c2 INT, CONSTRAINT PK_c1_c2 PRIMARY KEY(c1, c2));
Query OK, 0 rows affected

obclient> desc test;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| c1    | int(11) | NO   | PRI | NULL    |       |
| c2    | int(11) | NO   | PRI | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set

例2では、c1、c2 列を主キー列として定義し、制約名を PK_c1_c2 としています。c1、c2 列の値は NULL にすることができず、かつ重複してはなりません。

主キー列を定義した後、主キーの削除をサポートしています。主キー制約に関するその他の操作については、列の制約タイプの定義を参照してください。

その他の列制約の定義

OceanBaseデータベースは、PRIMARY KEY 制約に加えて、NOT NULL 制約、一意性（UNIQUE）制約、外部キー（FOREIGN KEY）制約、および CHECK 制約をサポートしています。制約を使用することで、テーブルクエリを簡略化し、クエリ性能を向上させるとともに、データの意味的な有効性を保証できます。

各制約タイプと説明は以下のとおりです：

• ノルルール（NOT NULL）：制約された列の値が NULL であることを許可しないことを示します。

  NOT NULL制約がある列については、列にNULLではないデフォルト値が定義されている場合を除き、INSERT ステートメントでその列の値を指定する必要があります。

• 一意性制約（UNIQUE）：制約された列の値に重複があることを許可しませんが、複数の NULL 値は存在できます。

• 外部キー制約（FOREIGN KEY）：制約された列の値が、別のテーブルの主キー列から取得されることを要求します。

  外部キー制約を作成する際、外部キー名を指定しない場合、システムは自動的に制約名を割り当てます。自動的に割り当てられる制約名は テーブル名_OBFK_作成タイムスタンプ の形式です。例：t1_OBFK_1627747200000000。

  OceanBaseデータベースは、デフォルトで外部キー制約チェックを有効にしています。外部キー制約チェックのスイッチは、テナント変数 foreign_key_checks によって制御されます。foreign_key_checks 変数の詳細については、foreign_key_checks を参照してください。

• CHECK 制約：データベース内の特定の列の値が指定された条件に適合することを要求します。

  単一の列に対して1つ以上の CHECK 制約を定義し、その列に特定の値のみを許可することができます。また、テーブルレベルの CHECK 制約を定義し、1つの CHECK 制約を複数の列に適用することもできます。テーブル名を変更すると、CHECK 制約名は変更されません。特定のテーブルを削除すると、そのテーブルに適用されている CHECK 制約も同時に削除されます。

  CHECK 制約を作成する際、制約名を指定しない場合、システムは自動的に制約名を割り当てます。自動的に割り当てられる制約名は テーブル名_OBCHECK_作成タイムスタンプ の形式です。例：t1_OBCHECK_1629350823880271。

単一の列を制約するには、その列の定義に制約キーワードを追加します。複数の列を制約するには、CREATE TABLE ステートメント内のすべての列のリストの後に、制約全体の定義を追加します。

以下は、その他の列制約を定義する際に従うべき要件です：

• NULL値が明確に存在しないフィールドには、NOT NULL 制約を追加することを推奨します。

• 別のテーブルの値を参照する必要がある場合は、外部キー制約を使用してください。

• 組み合わせ主キーは外部キーとして使用できません。

• 列に重複値が発生するのを防ぐ必要がある場合は、一意性制約を使用してください。

• NOT NULL 制約以外の制約については、その名前を明示的に指定することを推奨します。例えば、一意性制約を「UNI_xxx」と命名し、外部キー制約を「FK_xxx」と命名します。

例3：テーブル tbl1 を作成し、列 col1 にノルルールを設定します。

obclient> CREATE TABLE tbl1(col1 INT NOT NULL,col2 INT);
Query OK, 0 rows affected

obclient> DESC tbl1;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| col1  | int(11) | NO   |     | NULL    |       |
| col2  | int(11) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set

例3では、後からデータを挿入する際、列 col1 に挿入する値は NULL にすることができません。

例4：テーブル tbl2 を作成し、列 col1 に一意性制約を設定します。

obclient> CREATE TABLE tbl2(col1 INT UNIQUE,col2 INT);
Query OK, 0 rows affected

obclient> desc tbl2;
+-------+---------+------+-----+---------+-------+
| Field | Type    | Null | Key | Default | Extra |
+-------+---------+------+-----+---------+-------+
| col1  | int(11) | YES  | UNI | NULL    |       |
| col2  | int(11) | YES  |     | NULL    |       |
+-------+---------+------+-----+---------+-------+
2 rows in set

例4では、列 col1 の値に重複があってはなりません。

例5：外部キー制約を作成します。

obclient> CREATE TABLE test(c1 INT, c2 INT, CONSTRAINT PK_c1 PRIMARY KEY(c1));
Query OK, 0 rows affected

obclient> CREATE TABLE tbl3(col1 INT PRIMARY KEY,col2 INT,CONSTRAINT FK_col2 FOREIGN KEY(col2) REFERENCES test(c1));
Query OK, 0 rows affected

obclient> SELECT * FROM information_schema.TABLE_CONSTRAINTS;
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
| CONSTRAINT_CATALOG | CONSTRAINT_SCHEMA | CONSTRAINT_NAME               | TABLE_SCHEMA | TABLE_NAME | CONSTRAINT_TYPE | ENFORCED |
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
| def                | xxx               | PRIMARY                       | xxx          | test       | PRIMARY KEY     | YES      |
| def                | xxx               | PRIMARY                       | xxx          | tbl3       | PRIMARY KEY     | YES      |
| def                | xxx               | FK_col2                       | xxx          | tbl3       | FOREIGN KEY     | YES      |
+--------------------+-------------------+-------------------------------+--------------+------------+-----------------+----------+
3 rows in set

例5では、テーブル tbl3 の列 col2 が別のテーブル test の主キー列 c1 と関連付けられています。作成が成功すると、information_schema.TABLE_CONSTRAINTS ビューで確認できます。

例6：テーブル tbl4 を作成し、列 col1 の値が 10 より大きいことを設定します。

obclient> CREATE TABLE tbl4(col1 INT CHECK(col1>10),col2 INT);
Query OK, 0 rows affected

obclient> INSERT INTO tbl4 VALUES(2,2);
ERROR 3819 (HY000): check constraint violated

obclient> INSERT INTO tbl4 VALUES(11,2);
Query OK, 1 row affected

例6では、列 col1 に CHECK 制約が追加されているため、後から列 col1 に 10 以下の値を挿入するとエラーが発生します。

その他の列制約を定義する詳細な操作については、列の制約タイプの定義 を参照してください。

テーブルの自動インクリメント列の定義

OceanBaseデータベースでは、テーブル作成時に特定の数値列の値が重複せず、かつ連番であることを保証する必要がある場合、その列の型を AUTO_INCREMENT として定義することができます。これが自動インクリメント列です。

自動インクリメント列には、自動インクリメントの開始値、インクリメント幅、およびキャッシュサイズの3つの重要なプロパティがあり、auto_increment_cache_size、auto_increment_increment、auto_increment_offset の3つのテナント変数によって制御されます。

ビジネスニーズに応じて、これら3つのシステム変数の値を変更できます。システム変数の操作方法については、パラメータとシステム変数の概要を参照してください。

自動インクリメント列を定義する際には、以下の要件に従う必要があります：

• AUTO_INCREMENT はデータ列のプロパティの一種であり、整数型のデータ列にのみ適用されます。

• AUTO_INCREMENT を持つデータ列は、NOT NULL プロパティを持たなければなりません。

• パーティションテーブルを作成する際に、自動インクリメント列をパーティションキーとして使用する場合、OceanBaseデータベース内ではその値はグローバルに一意ですが、パーティション内では連番であることは保証されません。

自動インクリメント列を作成後、INSERT ステートメントでデータを挿入する際にその列の値を指定し、システム変数 SQL_MODE が NO_AUTO_VALUE_ON_ZERO に設定されていない場合、指定された値が 0 の場合、システムは次の自動インクリメント値で列を埋めます。指定された値が現在の最大値より小さい場合、次の自動インクリメント値の計算には影響しません。指定された値が現在の最大値より大きい場合、自動インクリメント列はこの挿入値とキャッシュ値の合計を次回の自動インクリメントの開始値とします。

例7：自動インクリメント列を含むテーブルを作成します。

obclient> CREATE TABLE personal_info(id bigint NOT NULL AUTO_INCREMENT PRIMARY KEY, name varchar(50), gmt_create timestamp NOT NULL default current_timestamp);
Query OK, 0 rows affected

例7では、id 列を自動インクリメント列に設定しているため、INSERT ステートメントでデータを挿入する際にその列の値を指定する必要はありません。システムが自動的に値を埋めます。

obclient> INSERT INTO personal_info(name) VALUES('A'),('B'),('C');
Query OK, 3 rows affected
Records: 3  Duplicates: 0  Warnings: 0

obclient> SELECT * FROM personal_info;
+----+------+---------------------+
| id | name | gmt_create          |
+----+------+---------------------+
|  1 | A    | 2020-04-03 17:09:55 |
|  2 | B    | 2020-04-03 17:09:55 |
|  3 | C    | 2020-04-03 17:09:55 |
+----+------+---------------------+
3 rows in set

自動インクリメント列の詳細や操作方法については、自動インクリメント列の定義を参照してください。

パーティション方式の選択

テーブル作成時には、テーブルのパーティション方式を明確に指定する必要があります。テーブルのデータ量が非常に大きい場合は、パーティション化を推奨します。パーティションテーブルを作成する際には、テーブルに格納されるデータに基づいて適切なパーティショニング方式を選択する必要があります。

OceanBaseデータベースのMySQLモードでは、単一テーブルでサポートされる最大パーティション数は、テナントレベルの構成パラメータ max_partition_num によって制御され、デフォルト値は8,192です。

OceanBaseデータベースのMySQLモードでは、パーティショニング方式に基づき、パーティションテーブルは以下のように分類されます：

• Rangeパーティション / Range Columnsパーティション

• Listパーティション / List Columnsパーティション

• Hashパーティション / keyパーティション

• 組み合わせパーティション

パーティションの次元に基づき、パーティションテーブルはさらにパーティションとサブパーティションに分けられます。サブパーティションはパーティションのさらなる分割であるため、パーティションテーブルには1つのパーティションキーが、サブパーティションテーブルには2つのパーティションキーが存在します。また、2回の分割戦略は異なる場合があります。OceanBaseデータベースでは、サブパーティションテーブルには、テンプレート付きサブパーティションテーブルと非テンプレート付きサブパーティションテーブルが含まれます。

パーティション関連の詳細については、パーティションの概要 を参照してください。

Rangeパーティション/Range Columnsパーティション

RangeパーティションとRange Columnsパーティションは、各パーティションのパーティションキー値の範囲に基づいてパーティションを分割します。通常、パーティションキーに対して範囲検索が必要な場合に適しています。例えば、日付フィールドや価格帯などに基づいて範囲パーティションを行う場合です。

RangeパーティションとRange Columnsパーティションの違いは以下の通りです：

• Rangeパーティションのパーティションキーは整数型でなければなりません。日付フィールドをパーティションにする場合は、関数を使用して変換する必要があります。例えば、dateフィールドをパーティションにする場合は、YEAR() 関数を使用して変換する必要があります。一方、Range Columnsパーティションのパーティションキーは整数である必要がなく、任意の型を指定できます。

• Rangeパーティションのパーティションキーには式を記述できますが、列（列ベクトル）は使用できません。例えば、partition by range(c1, c2) と書くことはできません。Range Columnsパーティションのパーティションキーには式を記述できませんが、複数の列（列ベクトル）は使用できます。

RangeパーティションとRange Columnsパーティションは、VALUES LESS THAN(value) キーワードを使用して各パーティションを定義します。ここで、value の値は連続して重複せず、小さい順から並んだ値でなければなりません。

例8：Range Columnsパーティションテーブルを作成します。

obclient> CREATE TABLE tb1_rc(col1 INT,col2 INT)
       PARTITION BY RANGE COLUMNS(col1)
        (PARTITION p0 VALUES LESS THAN(100),
         PARTITION p1 VALUES LESS THAN(200),
         PARTITION p2 VALUES LESS THAN(300)
        );
Query OK, 0 rows affected

例8では、Range Columnsパーティションのパーティションキーは任意の型を指定できるため、col1 列名をパーティションキーとして使用できます。その結果、パーティションテーブル tb1_rc は 100、200、300 の値の範囲に基づいてパーティション化されます。p0、p1、p2 は指定されたパーティション名であり、カスタマイズ可能です。同一テーブル内で各パーティション名が重複しないことを保証する必要があります。

Listパーティション/List Columnsパーティション

Listパーティションは、特定の値に基づいてパーティションを分割し、各パーティションの値は互いに重複しません。Listパーティションの利点は、順序がない、または無関係なデータセットを容易にパーティション化できることです。

複数列のListパーティションや、他のデータ型を使用したListパーティションを作成する場合は、List Columnsパーティションを利用できます。List ColumnsパーティションはListパーティションの拡張機能であり、複数のパーティションキーをサポートし、INTデータ型、DATE型、DATETIME型もサポートしています。

ListパーティションとList Columnsパーティションの違いは以下の通りです：

• Listパーティションのパーティションキーは整数型でなければなりませんが、List Columnsパーティションのパーティションキーは任意の型を指定できます。

• Listパーティションは単一のパーティションキーのみをサポートし、そのキーは1列または式となります。List Columnsパーティションのパーティションキーは式とすることはできませんが、複数列（列ベクトル）を指定できます。

ListパーティションとList Columnsパーティションは、VALUES IN(value_list) キーワードを使用して各パーティションを定義します。

例9：Listパーティションテーブルを作成します。

obclient> CREATE TABLE tbl2_l (col1 INT,col2 DATE)
       PARTITION BY LIST(col1)
        (PARTITION p0 VALUES IN (100),
         PARTITION p1 VALUES IN (200)
        );
Query OK, 0 rows affected

例9では、Listパーティションのパーティションキーは整数型でなければならないため、col1 列をパーティションキーとして使用します。その結果、パーティションテーブル tbl2_l は 100、200 の範囲に基づいて値がパーティション化されます。

Hashパーティション/keyパーティション

Hashパーティションでは、パーティションキーとパーティション数を指定する必要があります。システムはHashのパーティション式を計算して整数を得て、この結果をパーティション数で割った余りによって、特定の行データがどのパーティションに属するかを決定します。

KeyパーティションはHashパーティションと同様に、パーティション数で割った余りによってデータがどのパーティションに属するかを決定します。違いは、システムがKeyパーティションキーに対して内部的なデフォルトのHash関数を適用した後で割り算を行う点です。そのため、ユーザーは通常、単純な計算だけでは特定の行がどのパーティションに属するかを知ることはできません。

KeyパーティションとHashパーティションの違いは以下の通りです：

• Hashパーティションのパーティションキーは整数でなければなりませんが、Keyパーティションにはこの要件がなく、文字列もサポートしています。

• Hashパーティションのパーティションキーは式をサポートしますが、Keyパーティションのパーティションキーは式とすることができません。

例10：HASHパーティションテーブル tbl3_h を作成します。

obclient> CREATE TABLE tbl3_h(col1 INT,col2 VARCHAR(50))
    PARTITION BY HASH(col1) PARTITIONS 2;
Query OK, 0 rows affected

例10では、Hashパーティションのパーティションキーは整数でなければならないため、col1 をパーティションキーとして使用して、テーブル tbl3_h を2つの区に分割します。テーブル作成時にパーティション名を指定しなかったため、パーティション名はシステムが命名規則に従って自動的に付けます。すなわち、各パーティションはそれぞれ p0、p1、...、pn と命名されます。

組み合わせパーティション（サブパーティション）

組み合わせパーティションは通常、最初に1つのパーティショニング方式を使用し、その後のサブパーティションで別の方式を使用するもので、業務テーブルのデータ量が非常に大きい場合に適しています。組み合わせパーティションを使用することで、複数のパーティショニング方式の利点を活かせます。

Rangeパーティション、Range Columnsパーティション、Listパーティション、List Columnsパーティション、Hashパーティション、Keyパーティションは、すべて組み合わせパーティションテーブルのサブパーティション方式として使用できます。OceanBaseデータベースでは、サブパーティションテーブルには、テンプレート付きサブパーティションテーブルと非テンプレート付きサブパーティションテーブルが含まれます。

以下の簡単な例を通じて、サブパーティションテーブルの作成方法を簡潔に紹介します。

例11：テンプレート付きRange Columns + Rangeパーティションテーブルを作成します。

obclient> CREATE TABLE tb1_m_rcr(col1 INT,col2 INT)
         PARTITION BY RANGE COLUMNS(col1)
         SUBPARTITION BY RANGE(col2)
         SUBPARTITION TEMPLATE
          (SUBPARTITION mp0 VALUES LESS THAN(3),
           SUBPARTITION mp1 VALUES LESS THAN(6),
           SUBPARTITION mp2 VALUES LESS THAN(9)
          )
          (PARTITION p0 VALUES LESS THAN(100),
           PARTITION p1 VALUES LESS THAN(200),
           PARTITION p2 VALUES LESS THAN(300)
          );
Query OK, 0 rows affected

obclient> SELECT table_name,partition_name,subpartition_name FROM information_schema.partitions;
+------------+----------------+-------------------+
| table_name | partition_name | subpartition_name |
+------------+----------------+-------------------+
| tb1_m_rcr  | p0             | p0smp0            |
| tb1_m_rcr  | p0             | p0smp1            |
| tb1_m_rcr  | p0             | p0smp2            |
| tb1_m_rcr  | p1             | p1smp0            |
| tb1_m_rcr  | p1             | p1smp1            |
| tb1_m_rcr  | p1             | p1smp2            |
| tb1_m_rcr  | p2             | p2smp0            |
| tb1_m_rcr  | p2             | p2smp1            |
| tb1_m_rcr  | p2             | p2smp2            |
+------------+----------------+-------------------+
9 rows in set

例11では、Rangeパーティションのパーティションキーは整数型である必要があるため、2次分割では直接 col2 列名をパーティションキーとして使用し、SUBPARTITION TEMPLATE キーワードを使用してテンプレート付きサブパーティションテーブルを作成します。テンプレート付きサブパーティションテーブルでは、各パーティションの下のサブパーティションはすべてテンプレート内のサブパーティション定義に従って分割されます。つまり、各パーティションの下のサブパーティションの定義はすべて同じです。この例では、まずRange Columnsパーティション方式でパーティションを分割し、その後Rangeパーティション方式で2次分割を行います。

また、テンプレート付きサブパーティションを作成する際、サブパーティションの定義を完了した後、個々のパーティション名を別途指定する必要はありません。システムが命名規則に従って一括して行います。各サブパーティションの命名規則は ($part_name)s($subpart_name) です。この例では、パーティション p0 に対応するサブパーティションの名前はそれぞれ p0smp0、p0smp1、p0smp2 となります。

例12：非テンプレート付きList + List Columnsパーティションテーブルを作成します。

obclient> CREATE TABLE tbl2_f_llc(col1 INT,col2 DATE)
       PARTITION BY LIST(col1)
       SUBPARTITION BY LIST COLUMNS(col2)
        (PARTITION p0 VALUES IN(100)
           (SUBPARTITION sp0 VALUES IN('2021/04/01'),
            SUBPARTITION sp1 VALUES IN('2021/07/01'),
            SUBPARTITION sp2 VALUES IN('2021/10/01'),
            SUBPARTITION sp3 VALUES IN('2022/01/01')
           ),
         PARTITION p1 VALUES IN(200)
           (SUBPARTITION sp4 VALUES IN('2021/04/01'),
            SUBPARTITION sp5 VALUES IN('2021/07/01'),
            SUBPARTITION sp6 VALUES IN('2021/10/01'),
            SUBPARTITION sp7 VALUES IN('2022/01/01')
            )
         );
Query OK, 0 rows affected

例12では、非テンプレート付きサブパーティションテーブルを作成するため、各パーティションに対してサブパーティションを定義する必要があります。各パーティションの下のサブパーティションの定義は同じでも異なっても構いません。

例13：非テンプレート付きHash + Keyパーティションテーブルを作成します。

obclient> CREATE TABLE tbl3_f_hk (col1 INT,col2 VARCHAR(50))
     PARTITION BY HASH(col1)
     SUBPARTITION BY KEY(col2)
      (PARTITION p1
       (SUBPARTITION sp0
       ,SUBPARTITION sp1
       ,SUBPARTITION sp2
       ,SUBPARTITION sp3
       ),
       PARTITION p2
       (SUBPARTITION sp4
       ,SUBPARTITION sp5
       ,SUBPARTITION sp6
       ,SUBPARTITION sp7
       )
      );
Query OK, 0 rows affected

例13では、Keyパーティションが文字列をパーティションキーとしてサポートしているため、col2 列をパーティションキーとして使用して2次分割を行います。ここで、sp0、……、sp7 は指定されたサブパーティション名です。

レプリケーションテーブルの作成

レプリケーションテーブルは、OceanBaseデータベースの特殊なテーブルです。このテーブルは、任意の「正常」なレプリカでデータの最新の変更を読み取ることができます。書き込み頻度が低く、読み取り頻度が高いシナリオにおいて、レプリケーションテーブルは優れた選択肢です。

レプリケーションテーブルの詳細については、管理者ガイドのテーブルの作成のレプリケーションテーブルの作成セクションを参照してください。

レプリケーションテーブルを作成するSQL構文は以下のとおりです：

CREATE TABLE table_name column_definition DUPLICATE_SCOPE='none | cluster';

パラメータの説明：

• table_name：テーブル名。

• column_definition：テーブルの列情報。例えば、列定義、主キー定義などです。

• DUPLICATE_SCOPE：レプリケーションテーブルの属性を指定するために使用されます。取り得る値は以下のとおりです：

  • none：このテーブルが通常のテーブルであることを示します。
  • cluster：このテーブルがレプリケーションテーブルであることを示します。Leaderはトランザクションを現在のテナントのすべてのFレプリカおよびRレプリカに複製する必要があります。

例14：以下のSQLステートメントを使用して、レプリケーションテーブルtest_tbl14を作成します。

CREATE TABLE test_tbl14 (col1 INT,col2 INT) DUPLICATE_SCOPE= 'cluster';

次のステップ

テーブル作成後、テーブルの使用と管理を整備するために、以下のいくつかの後続操作を実行する必要が生じる場合があります：

• テーブル作成後は、INSERT ステートメントを使用してテーブルにデータを挿入できます。データ挿入の詳細については、データの挿入を参照してください。

• クエリのパフォーマンスを向上させる必要がある場合は、テーブルの列にインデックスを作成できます。インデックス作成の詳細については、インデックスの作成を参照してください。

関連ドキュメント

• テーブルのプロパティを表示する方法の詳細については、テーブルの定義の表示を参照してください。
• テーブルの削除方法の詳細については、テーブルの削除を参照してください。
• テーブル構造の変更方法の詳細については、テーブルの変更を参照してください。
• パーティションテーブルの作成方法の詳細については、パーティションテーブルの作成を参照してください。