为什么不使用记录的创建时间作为主键？

Question

我有一个表，它有一个自动递增的PK和creation_date字段，它是unix时间戳。
我想知道为什么不丢失自动增量字段并使用创建日期字段作为PK，因为它是唯一的（我使用1/1000秒的精度）。

因为：我正在杀死一个索引行 反对：复制的可能性很小（非常轻微），但很容易处理这种非常罕见的事件。

数据库是mysql。

Answer 1

一般的答案是你的数据可能会改变（无意义的id永远不会发生）...当你意识到你在本地区域存储时间并且DST开始时会发生什么？如果您想针对UTC和/或针对特定时区进行存储？有关更多订购注意事项，请参阅wcoenen's answer。

如果你开始每秒创建1000行，并且你不得不乱用数据来“使其工作”做一些不适合的事情。也许你会添加一个消歧列，它会使你的索引更大更慢......

然后当你的项目变得非常流行并且人们开始尝试运行报告/查询并且“它使用日期作为PK ??? !!!”

还要考虑使用允许非主列上的聚簇索引的数据库。

Answer 2

由于索引的大小（宽度）。时间戳很宽;除非你的表包含一堆行，否则你不需要bigint作为PK的数据类型。主键列越薄，您可以一次保留在内存中的索引块大小越大，查询越快。所以不要这样做。

Answer 3

糟糕的主意，因为“时区”。

如果托管您服务器的国家/地区观察到与“夏令时”计划相关的时间变化，那么每年一次的时间将会缩短一小时。

然后一小时，它将生成重复的密钥。

我曾在一家公司工作，该公司拥有一个带有时间戳键的数据库，每小时记录一次来自半导体制造工厂设备的数千次测量。它是在韩国开发的（没有夏令时变换）。

当他们在美国安装它时...... 我们每年必须关闭整个工厂一小时 - 以免在那一小时内丢失测量值。 ： - ）

Answer 4

PC或服务器通常synchronize their clock with a time server。正因为如此，你不能依靠系统时钟保持稳定的前进步伐。它可能随时向后或向前跳跃。

因此，如果您必须能够重建记录的创建顺序，则需要自动增加PK。你不能依赖时间戳。这听起来很理论，但它已经咬了我们。

Answer 5

不拥有自动递增的PK会让您获得什么？

Answer 6

因为：

  

反对：复制的可能性很小（非常轻微），但很容易处理这种非常罕见的事件。

您无法保证您的密钥始终是唯一的，因此该信息不适合主密钥。

如果您必须批量插入10或100条记录，该怎么办？您是否会在插入之间插入暂停以确保您具有唯一的主键？

Answer 7

时间不够精确，如果同时插入两条记录，最终可能会导致插入失败。

Answer 8

  

For：我正在查杀索引行。

反对：...支持另一个索引行，由于其长度非常大，如果使用频率更高，将导致显着增加的开销。

Answer 9

基本答案是它没有扩展。它可能现在可以正常工作，但随着计算机变得越来越快，并且您获得更多用户，它迟早会开始冲突并限制系统的吞吐量。

然后就像其他人指出的那样，有很多基本的技术原因。