テーブルの作成

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

テーブルの概要

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

前提条件

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

• OceanBaseクラスタをデプロイし、MySQLモードのテナントを作成していること。詳細な操作については、クラスタインスタンスの作成およびテナントの作成をご参照ください。

• 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 にすることができず、かつ重複してはなりません。

プライマリキー列を定義した後、プライマリキーを削除することが可能です。プライマリキー制約に関連するその他の操作については、列の制約タイプの定義に関するドキュメントをご参照ください。

その他の列制約の定義

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

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

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

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

• UNIQUE制約 (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 によって制御され、デフォルト値は8192です。

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パーティションのパーティションキーは式とすることはできませんが、複数列（列ベクトル）を指定できます。

リストパーティションとリストカラムパーティションでは、VALUES IN(value_list) キーワードを使用して各パーティションを定義します。

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

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では、リストパーティションのパーティションキーは整数型でなければならないため、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 と命名されます。

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

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

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パーティションのパーティションキーは整数型である必要があるため、サブパーティションでは直接 col2 列名をパーティションキーとして使用し、SUBPARTITION TEMPLATE キーワードを使用してテンプレート型サブパーティションテーブルを作成します。テンプレート型サブパーティションテーブルでは、各パーティションの下のサブパーティションはすべてテンプレート内のサブパーティション定義に従います。つまり、各パーティションの下のサブパーティション定義はすべて同じです。この例では、まず Range Columns パーティション方式でパーティションを作成し、次に Range パーティション方式でサブパーティションを作成します。

また、テンプレート型サブパーティションを作成する際、サブパーティションの定義を完了した後、個々のパーティション名を別途指定する必要はありません。システムが命名規則に基づいて一括して行います。各サブパーティションの命名規則は ($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 列をパーティションキーとして使用して二次分割できます。ここで、sp0、……、sp7 は指定されたサブパーティション名です。

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

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

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

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

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

パラメータの説明：

• table_name：テーブル名。

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

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

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

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

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

次のステップ

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

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

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

関連ドキュメント

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