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

回答