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 数据库：聚集索引支持，那么您可能会在 Thomas Mueller 的回答中找到以下语句：

如果在创建表之后创建主键，则主键存储在新的索引 b-tree 中。

因此，如果语句按照它们显示在 INFORMATION_SCHEMA 中的方式执行，则在创建表后创建主键，因此在聚集索引中不使用 ID（基本上作为数据 b 树中的键）。

有没有一种方法可以保证在 H2 的聚集索引中使用主键？

4

1 回答 1

2

TABLES 和 CONSTRAINS 中的信息是否反映了在数据库中执行的真实 SQL？

是的。基本上，这些是打开数据库时运行的语句。

如果你看看我之前的问题

答案“如果在创建表后创建主键......”不正确，我现在将其修复为“如果在插入数据后创建主键......”。

有没有一种方法可以保证主键在 H2 中用作聚集索引？

这现在在H2​​ 文档中的“数据如何在内部存储”中得到更好的描述：“如果在创建表时（或在创建表之后，但之前指定了 BIGINT、INT、SMALLINT、TINYINT 类型的单列主键）插入任何行），则此列用作数据 b 树的键。”

于 2010-10-06T12:04:18.833 回答