TiDB Cloud
TiDB Self-Managed
Learning Center
お問い合わせ

制約

TiDB は、MySQL とほぼ同じ制約をサポートしています。

ヌルではない

TiDB でサポートされている NOT NULL 制約は、MySQL でサポートされているものと同じです。

例えば：

CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 age INT NOT NULL,
 last_login TIMESTAMP
);

INSERT INTO users (id,age,last_login) VALUES (NULL,123,NOW());

Query OK, 1 row affected (0.02 sec)

INSERT INTO users (id,age,last_login) VALUES (NULL,NULL,NOW());

ERROR 1048 (23000): Column 'age' cannot be null

INSERT INTO users (id,age,last_login) VALUES (NULL,123,NULL);

Query OK, 1 row affected (0.03 sec)
  • AUTO_INCREMENT列にNULLを代入できるため、最初のINSERTステートメントは成功します。 TiDB はシーケンス番号を自動的に生成します。
  • age列がNOT NULLとして定義されているため、2 番目のINSERTステートメントは失敗します。
  • 3 列がNOT NULLとして明示的に定義されていないため、 last_login番目のINSERTステートメントは成功します。デフォルトでは NULL 値が許可されています。

チェック

TiDB は解析しますが、 CHECK制約を無視します。これはMySQL 5.7互換の動作です。

例えば：

DROP TABLE IF EXISTS users;
CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(60) NOT NULL,
 UNIQUE KEY (username),
 CONSTRAINT min_username_length CHECK (CHARACTER_LENGTH(username) >=4)
);
INSERT INTO users (username) VALUES ('a');
SELECT * FROM users;

ユニークキー

一意の制約とは、一意のインデックスと主キー列のすべての非 null 値が一意であることを意味します。

楽観的な取引

デフォルトでは、楽観的トランザクションの場合、TiDB は実行フェーズで一意の制約怠惰にをチェックし、コミット フェーズで厳密にチェックします。これにより、ネットワーク オーバーヘッドが削減され、パフォーマンスが向上します。

例えば：

DROP TABLE IF EXISTS users;
CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(60) NOT NULL,
 UNIQUE KEY (username)
);
INSERT INTO users (username) VALUES ('dave'), ('sarah'), ('bill');

楽観的ロックとtidb_constraint_check_in_place=OFFの場合:

BEGIN OPTIMISTIC;
INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');

Query OK, 3 rows affected (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 0

INSERT INTO users (username) VALUES ('steve'),('elizabeth');

Query OK, 2 rows affected (0.00 sec)
Records: 2  Duplicates: 0  Warnings: 0

COMMIT;

ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username'

前の楽観的例では、一意のチェックはトランザクションがコミットされるまで延期されました。値billが既に存在していたため、重複キー エラーが発生しました。

tidb_constraint_check_in_placeからONを設定すると、この動作を無効にできます。 tidb_constraint_check_in_place=ONの場合、ステートメントの実行時に一意制約がチェックされます。この変数は楽観的トランザクションにのみ適用されることに注意してください。悲観的トランザクションの場合、変数tidb_constraint_check_in_place_pessimisticを使用してこの動作を制御できます。

例えば：

DROP TABLE IF EXISTS users;
CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(60) NOT NULL,
 UNIQUE KEY (username)
);
INSERT INTO users (username) VALUES ('dave'), ('sarah'), ('bill');

SET tidb_constraint_check_in_place = ON;

Query OK, 0 rows affected (0.00 sec)

BEGIN OPTIMISTIC;

Query OK, 0 rows affected (0.00 sec)

INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');

ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username'

最初のINSERTステートメントで重複キー エラーが発生しました。これにより、追加のネットワーク通信オーバーヘッドが発生し、挿入操作のスループットが低下する可能性があります。

悲観的な取引

悲観的トランザクションでは、一意のインデックスを挿入または更新する必要がある SQL ステートメントが実行されると、TiDB はデフォルトでUNIQUE制約をチェックします。

DROP TABLE IF EXISTS users;
CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 username VARCHAR(60) NOT NULL,
 UNIQUE KEY (username)
);
INSERT INTO users (username) VALUES ('dave'), ('sarah'), ('bill');

BEGIN PESSIMISTIC;
INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill');

ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username'

悲観的トランザクションのパフォーマンスを向上させるために、変数tidb_constraint_check_in_place_pessimisticをOFFに設定できます。これにより、TiDB は一意のインデックスの一意の制約チェックを延期できます (次にこのインデックスがロックを必要とするとき、またはトランザクションがコミットされるときまで)。 ) 対応する悲観的ロックをスキップします。この変数を使用する場合は、次の点に注意してください。

  • 遅延一意制約チェックにより、悲観的トランザクションをコミットすると、TiDB は一意制約を満たさない結果を読み取り、 Duplicate entryエラーを返す場合があります。このエラーが発生すると、TiDB は現在のトランザクションをロールバックします。

    次の例では、ロックをbillにスキップするため、TiDB は一意性の制約を満たさない結果を取得する可能性があります。

    SET tidb_constraint_check_in_place_pessimistic = OFF;
BEGIN PESSIMISTIC;
INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); -- Query OK, 3 rows affected
SELECT * FROM users FOR UPDATE;

    次の出力例のように、TiDB のクエリ結果には 2 つのbills含まれており、一意性制約を満たしていません。

    +----+----------+
| id | username |
+----+----------+
| 1  | dave     |
| 2  | sarah    |
| 3  | bill     |
| 7  | jane     |
| 8  | chris    |
| 9  | bill     |
+----+----------+

    この時点で、トランザクションがコミットされると、TiDB は一意制約チェックを実行し、 Duplicate entryエラーを報告して、トランザクションをロールバックします。

    COMMIT;

    ERROR 1062 (23000): Duplicate entry 'bill' for key 'users.username'

  • この変数が無効になっている場合、データの書き込みが必要な悲観的トランザクションをコミットすると、 Write conflictエラーが返される場合があります。このエラーが発生すると、TiDB は現在のトランザクションをロールバックします。

    次の例のように、2 つの同時トランザクションが同じテーブルにデータを挿入する必要がある場合、悲観的ロックをスキップすると、トランザクションをコミットするときに TiDB がWrite conflictエラーを返します。そして、トランザクションはロールバックされます。

    DROP TABLE IF EXISTS users;
CREATE TABLE users (
id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
username VARCHAR(60) NOT NULL,
UNIQUE KEY (username)
);

SET tidb_constraint_check_in_place_pessimistic = OFF;
BEGIN PESSIMISTIC;
INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); -- Query OK, 3 rows affected

    同時に、別のセッションが同じテーブルにbillを挿入します。

    INSERT INTO users (username) VALUES ('bill'); -- Query OK, 1 row affected

    次に、最初のセッションでトランザクションをコミットすると、TiDB はWrite conflictエラーを報告します。

    COMMIT;

    ERROR 9007 (HY000): Write conflict, txnStartTS=435688780611190794, conflictStartTS=435688783311536129, conflictCommitTS=435688783311536130, key={tableID=74, indexID=1, indexValues={bill, }} primary={tableID=74, indexID=1, indexValues={bill, }}, reason=LazyUniquenessCheck [try again later]

  • この変数が無効になっている場合、悲観的トランザクションで DML ステートメントを実行すると、エラー8147: LazyUniquenessCheckFailureが返される場合があります。

    ノート：

    8147エラーが発生すると、TiDB は現在のトランザクションをロールバックします。

    次の例のように、 INSERTステートメントの実行時に、TiDB はロックをスキップします。次に、 DELETEステートメントの実行時に、TiDB は一意のインデックスをロックし、一意の制約をチェックするため、 DELETEステートメントでエラーが報告されることがわかります。

    SET tidb_constraint_check_in_place_pessimistic = OFF;
BEGIN PESSIMISTIC;
INSERT INTO users (username) VALUES ('jane'), ('chris'), ('bill'); -- Query OK, 3 rows affected
DELETE FROM users where username = 'bill';

    ERROR 8147 (23000): transaction aborted because lazy uniqueness check is enabled and an error occurred: [kv:1062]Duplicate entry 'bill' for key 'users.username'

  • この変数が無効になっている場合、 1062 Duplicate entryエラーは現在の SQL ステートメントからのものではない可能性があります。したがって、トランザクションが同じ名前のインデックスを持つ複数のテーブルで動作する場合は、エラー メッセージ1062をチェックして、実際にどのインデックスからエラーが発生したかを確認する必要があります。

主キー

MySQL と同様に、主キー制約には一意の制約が含まれます。つまり、主キー制約を作成することは、一意の制約を持つことと同じです。さらに、TiDB のその他の主キー制約も、MySQL のものと似ています。

例えば：

CREATE TABLE t1 (a INT NOT NULL PRIMARY KEY);

Query OK, 0 rows affected (0.12 sec)

CREATE TABLE t2 (a INT NULL PRIMARY KEY);

ERROR 1171 (42000): All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead

CREATE TABLE t3 (a INT NOT NULL PRIMARY KEY, b INT NOT NULL PRIMARY KEY);

ERROR 1068 (42000): Multiple primary key defined

CREATE TABLE t4 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a,b));

Query OK, 0 rows affected (0.10 sec)
  • 列aが主キーとして定義されており、NULL 値が許可されていないため、表t2を作成できませんでした。
  • テーブルには 1 つの主キーしか持てないため、テーブルt3を作成できませんでした。
  • 主キーは 1 つしか存在できませんが、TiDB は複数の列を複合主キーとして定義することをサポートしているため、表t4正常に作成されました。

上記のルールに加えて、TiDB は現在、 NONCLUSTERED種類の主キーの追加と削除のみをサポートしています。例えば：

CREATE TABLE t5 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a,b) CLUSTERED);
ALTER TABLE t5 DROP PRIMARY KEY;

ERROR 8200 (HY000): Unsupported drop primary key when the table is using clustered index

CREATE TABLE t5 (a INT NOT NULL, b INT NOT NULL, PRIMARY KEY (a,b) NONCLUSTERED);
ALTER TABLE t5 DROP PRIMARY KEY;

Query OK, 0 rows affected (0.10 sec)

CLUSTERED型の主キーの詳細については、 クラスター化インデックスを参照してください。

外部キー

ノート：

TiDB では、外部キー制約のサポートが制限されています。

TiDB は、DDL コマンドでのFOREIGN KEY制約の作成をサポートしています。

例えば：

CREATE TABLE users (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 doc JSON
);
CREATE TABLE orders (
 id INT NOT NULL PRIMARY KEY AUTO_INCREMENT,
 user_id INT NOT NULL,
 doc JSON,
 FOREIGN KEY fk_user_id (user_id) REFERENCES users(id)
);

SELECT table_name, column_name, constraint_name, referenced_table_name, referenced_column_name
FROM information_schema.key_column_usage WHERE table_name IN ('users', 'orders');

+------------+-------------+-----------------+-----------------------+------------------------+
| table_name | column_name | constraint_name | referenced_table_name | referenced_column_name |
+------------+-------------+-----------------+-----------------------+------------------------+
| users      | id          | PRIMARY         | NULL                  | NULL                   |
| orders     | id          | PRIMARY         | NULL                  | NULL                   |
| orders     | user_id     | fk_user_id      | users                 | id                     |
+------------+-------------+-----------------+-----------------------+------------------------+
3 rows in set (0.00 sec)

TiDB は、 ALTER TABLEコマンドを介してDROP FOREIGN KEYおよびADD FOREIGN KEYへの構文もサポートします。

ALTER TABLE orders DROP FOREIGN KEY fk_user_id;
ALTER TABLE orders ADD FOREIGN KEY fk_user_id (user_id) REFERENCES users(id);

ノート

  • TiDB は、他のデータベースから TiDB にデータを移行するときにこの構文によって引き起こされるエラーを回避するために、外部キーをサポートしています。

    ただし、TiDB は DML ステートメントの外部キーに対して制約チェックを実行しません。たとえば、users テーブルに id=123 のレコードがなくても、次のトランザクションは正常に送信できます。

    START TRANSACTION;
INSERT INTO orders (user_id, doc) VALUES (123, NULL);
COMMIT;

このページは役に立ちましたか？