由于您似乎将“id/index”混为一谈,让我们稍微谈谈关系数据库上下文中的主键和索引。
分配给 SQL 数据库中一行的“id”或主键是该行的唯一标识符。它可以由一列或多列组成。(当涉及多个列时,它被称为“复合”或“多部分”键。)主键实际上应该只是用于寻址行的唯一句柄:主键不应该包含任何有关由该行表示的实体的信息,特别是如果该信息有可能是可变的;一个例子是具有后缀的零件编号,该后缀代表零件的金属类型;如果该金属可能从钛变为 unobtainium,例如,该零件号将作为主键的错误选择;最好有另一列来存储金属的类型,而不是将金属类型的后缀作为主键的一部分。“有意义的”主键在遗留的非关系数据库中可能有意义,但在关系数据库中它们应该被避免。
当寻求强制主键的唯一性时,数据库引擎可以利用索引来快速测试键值是否存在。它可以使用二进制算法来查找值,避免需要逐行扫描实际数据“蛮力”,寻找值。 但是引擎在幕后使用的索引来帮助它进行主键管理与主键本身是不同的。
如果您有一个简单的连续整数作为主键,那么它们的数量是无限的,因此当分配给它的行已被删除时,当它变得可用时,无需重用整数。因此,关系数据库引擎不会自动尝试重用它,并且当数字序列中的“间隙”由删除。其他表中的许多其他行可能正在引用这些值,并且让它们可变会造成混乱或极大的低效率。
Hashing algorithms are another very efficient way a database engine can quickly test for the existence of a key value. It computes the location in the hashed-file where the key would be if it did exist, and then looks there for it. The rows are stored in no particular order, so such schemes are optimized for instant finding of records in a large table, not for culling records that have a common characteristic, such as all customers in zipcode 10023.