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

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

因为:我正在杀死一个索引行.
反对:复制的可能性很小(非常轻微),但很容易处理这种非常罕见的事件.

DB是mysql.

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

如果你开始每秒创建1000行,并且你不得不搞乱数据以"使其工作"做一些它不适合的事情.也许你会添加一个消歧列,使你的指数更大更慢......

然后当你的项目变得大受欢迎时,人们开始尝试运行报告/查询,并且"它使用日期作为PK ??? !!!"

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

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

不好的想法,因为"时区".

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

然后一小时,它将生成重复的键.

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

当他们在美国安装它时...... 我们不得不每年关闭整个工厂一小时 - 以免在那一小时内丢失测量值.:-)

PC或服务器通常将其时钟与时间服务器同步.正因为如此,你不能依靠系统时钟保持稳定的前进步伐.它可以随时轻微地向后或向前跳跃.

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