H2數據庫：關於INFORMATION_SCHEMA

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

這些陳述不是我所陳述的那些，因此，問題是：是表中的信息和約束反映了在數據庫中執行的怎麼樣真正的SQL？

實際的原因，我要問的問題是，我不知道我應該順序執行，以保證該主鍵是在聚集索引中使用的語句。如果你看一下我剛纔的問題H2 database: clustered index support那麼你可能在托馬斯·穆勒下面的語句的答案發現：

如果主鍵是表被創建後創建則主密鑰存儲在一個新的索引b-tree。

因此，如果語句按照這種方式執行，它們將顯示在INFORMATION_SCHEMA中，那麼將在創建表之後創建主鍵，因此在聚集索引中不使用ID（基本上作爲數據b-樹）。

有沒有辦法如何保證主鍵在H2中的聚集索引中使用？

2010-10-06 Tim

TABLES和CONSTRAINS中的信息是否反映了數據庫中執行的真實SQL？

是。基本上，這些是打開數據庫時運行的語句。

如果你看一下我剛纔的問題

回答「如果表已經創建之後主鍵創建...」是不正確的，我現在固定爲「如果主在插入數據後創建密鑰......「。

有沒有辦法如何保證主鍵在H2中用作聚簇索引？「如果在創建表時指定類型BIGINT，INT，SMALLINT，TINYINT的單個列主鍵（或剛創建後：

現在這是在H2 documentation在「數據如何在內部存儲」更好地描述該表，但在插入任何行之前），則此列將用作數據B樹的關鍵字。「

2010-10-06 12:04:18

回答