1

H2 で次のテーブルを作成します。

CREATE TABLE TEST
(ID BIGINT NOT NULL PRIMARY KEY)

次に、INFORMATION_SCHEMA.TABLES テーブルを調べます。

SELECT SQL 
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_NAME = 'TEST'

結果：

CREATE CACHED TABLE TEST(
    ID BIGINT NOT NULL
)

次に、INFORMATION_SCHEMA.CONSTRAINTS テーブルを調べます。

SELECT SQL 
FROM INFORMATION_SCHEMA.CONSTRAINTS
WHERE TABLE_NAME = 'TEST'

結果：

ALTER TABLE TEST 
ADD CONSTRAINT CONSTRAINT_4C 
PRIMARY KEY(ID) 
INDEX PRIMARY_KEY_4C

これらのステートメントは私が述べたものではありません。したがって、質問は次のとおりです。TABLES と CONSTRAINS の情報は、データベースで実行された実際の SQL をどのように反映していますか?

  1. 元の CREATE TABLE ステートメントには、CACHEDという単語はありませんでした。（問題ない）
  2. ALTER TABLE .. ADD CONSTRAINTステートメントを実行したことがありません。

私が質問をしている実際の理由は、主キーがクラスター化インデックスで使用されることを保証するためにどのステートメントを実行すればよいかわからないためです。私の以前の質問H2 database: clustered index supportを見ると、Thomas Mueller の回答に次のステートメントが見つかるかもしれません。

テーブルの作成後に主キーが作成された場合、主キーは新しいインデックス B ツリーに格納されます。

したがって、INFORMATION_SCHEMA に示されているようにステートメントを実行すると、テーブルの作成後に主キーが作成されるため、ID はクラスター化インデックスで (基本的にデータ B ツリーのキーとして) 使用されません。

H2 のクラスター化インデックスで主キーが使用されていることを保証する方法はありますか?

4

1 に答える 1

2

TABLES と CONSTRAINS の情報は、データベースで実行された実際の SQL を反映していますか?

はい。基本的に、これらはデータベースを開くときに実行されるステートメントです。

私の過去の質問を見れば

「テーブルを作成した後に主キーを作成すると…」という回答が間違っていたので、「データを挿入した後に主キーを作成すると…」に修正しました。

H2 で主キーがクラスター化インデックスとして使用されることを保証する方法はありますか?

これは、H2 のドキュメントの「How Data is Stored Internally」でより適切に説明されています。「テーブルの作成時 (またはテーブルの作成直後、ただし、行を挿入する)、この列はデータ B ツリーのキーとして使用されます。」

于 2010-10-06T12:04:18.833 に答える