主键理论与 I/O 效率

Posted 2023-03-27

【中文标题】主键理论与 I/O 效率

【英文标题】：Primary Key Theory & I/O Efficiency

【发布时间】：2019-09-13 17:34:29

【问题描述】：

根据 RSBMS 理论，在选择主键时，我们应该在最少的超级键中进行选择，从而有效地优化我们的键选择 w.r.t # 列。

为什么我们对优化列数而不是字节数感兴趣？较小的字节大小 PK 不会导致更小的索引表和整体上更高效的读/写时间查询吗？例如，选择由 2 个 varchar(16) 而不是 1 个 varchar(64) 组成的 PK。

【问题讨论】：

RDBMS 理论并没有说明 PK；传统做法可以。 PK 是您决定将其称为 PK 的某些 CK。 RDBMS 理论对实现只字未提。 CKs 和 superkeys 是一些与规范化和其他理论和实践相关的有用的关系数据库事物。 CK 是“最小的”超级键这一事实与实现无关。某个有用的东西恰好是某个其他有用的东西的某个特例。 PS 请注意，SQL PRIMARY KEY 声明声明了一个超级键（SQL 类似物）——可以在其中声明一个较小的 UNIQUE。

啊，好吧。这消除了一些混乱。谢谢。

我认为 philipxy 和 nvogel 是对的。超级键是省略一列在其他字段中仍然具有唯一性的地方，因此您的两个 16 字节字段与一个 64 字节字段的示例不是超级键。

【参考方案1】：

我想我同意你的看法。

我认为理论不能解释物理存储。

是的，例如，如果您创建了一个由两个小列组成的 SHA256 列，例如 VARCHAR(16)，那么是的，索引中 B 树的节点会占用更多空间，而索引不会比索引两个 16 字节列更快。

在第一列上建立一个匹配的索引会降低效率，并且必须切换到第二列上的比较。如果整个 b 节点在同一列上进行比较，则 b 节点效率更高。

但老实说，我认为两者在效率上都没有太大差异。我认为该声明是 RDBMS 理论，没有考虑存储大小。

【参考方案2】：

在定义数据库中的键时，识别最小而不是非最小超级键非常重要。如果您选择对三列 A、B、C 强制唯一性，那么这与仅对两列 A、B 强制唯一性非常不同。 A,B,C 的唯一性约束不能保证 A,B 的唯一性 - 所以 A,B 将不再是超键。另一方面，如果唯一性约束在 A,B 上，则 A,B,C 也是超键。因此，从数据完整性的角度来看，了解不可约的超级密钥集是什么是必不可少的。

这与主键无关，因为 所有 键必须是最小的，而不仅仅是您选择称为主键的那个。存储大小和性能是另一回事。内部存储是索引设计中的一个重要考虑因素，但大小和性能是非功能性要求，而键是关于逻辑和功能性的。