テーブルの作成

本トピックでは、SQL文を使用してテーブルを作成する方法について説明し、テーブル作成の前提条件、テーブルの概要、従うべき要件、およびいくつかの例を紹介します。

テーブルの概要

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

前提条件

テーブルを作成する前に、以下の事項を確認する必要があります。

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

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

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

• CREATE 特権を持っていること。現在のユーザーの特権を確認する操作については、テナントアカウント管理をご参照ください。

コマンドラインを使用したテーブルの作成

CREATE TABLE 文を使用してテーブルを作成します。

テーブル名の定義

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

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

• テーブル名は64文字を超えることはできません。

• テーブルには意味のある名前を付けることをお勧めします。t1 や table1 のようなテーブル名は使用しないでください。テーブルの命名規則の詳細については、テーブルの命名規則をご参照ください。

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

CREATE TABLE orders (...);

列の定義

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

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

• データ型の特性に基づいて、列に保存するデータに適切なデータ型を選択します。

• 文字列データの場合、可変長文字列データ型を使用し、最大長を指定することをお勧めします。指定した最大長が保存する必要のある最大文字数よりも大きいことを確認し、最大長を超えた場合の文字の切り捨てを防いでください。

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

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

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

主キー列の定義

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

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

主キー列を定義する際に従うべき要件は以下のとおりです。

• テーブルに主キーを定義することをお勧めします。各データベーステーブルは最大で1つの主キー列の集合を持つことができます。

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

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

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

• 主キー列の数は64列を超えることはできず、主キーデータの合計長は16 KBを超えることはできません。

• 主キー列の値は 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 制約もサポートしています。制約を使用することで、テーブルクエリを簡素化し、クエリパフォーマンスを向上させ、データが意味的に有効であることを保証できます。

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

• 非NULL制約（NOT NULL）：制約に含まれる列の値が NULL になることを許可しないことを示します。

  非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 に非NULL制約を設定します。

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 はデータ列の属性の1つであり、整数型のデータ列にのみ適用されます。

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

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 パーティションのパーティションキーは整数型であることが要求されるため、二次パーティションでは 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：このテーブルがレプリケーションテーブルであることを示します。Leaderはトランザクションを現在のテナントのすべてのFレプリカおよびRレプリカに複製する必要があります。

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

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

次のステップ

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

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

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

関連情報