Database 主键理论与I/O效率

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

---

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

我想我同意你的看法

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

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

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

---

老实说，我不认为两者在效率上有多大差别。我认为这是RDBMS理论，没有考虑存储大小。

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

---

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

RDBMS理论没有说明PKs；传统做法确实如此。PK是您决定称之为PK的某个CK。RDBMS理论没有提到实现。CKs和superkeys是一些与规范化和其他理论与实践相关的有用的关系数据库。CKs是最小超键这一事实与实现无关。某件有用的东西恰好是另一件有用的东西的某个特例。请注意，SQL主键声明声明了与超级键类似的SQL，可以在其中声明一个较小的UNIQUE。啊，好的。这消除了一点混乱。谢谢。我想菲利普西和恩沃格尔是对的。如果省略一列，则超级键在其他字段中仍然具有唯一性，因此您的两个16字节字段与一个64字节字段的示例不是超级键。