Mysql 时间戳和 AUTO_INCREMENT 作为主键答案

【问题标题】：Mysql timestamp and AUTO_INCREMENT as primary keyMysql 时间戳和 AUTO_INCREMENT 作为主键
【发布时间】：2021-05-10 23:44:08
【问题描述】：

我正在考虑为我的数据编制索引的最佳方式。使用时间戳作为我的主键是个好主意吗？无论如何我都在保存它，我想保存一些列。由于性能原因，时间戳应该是整数而不是日期时间列。此外，我不想在短时间内（两秒之间）限制数据量。因此，我想到了一个额外的 AUTO_INCREMENT 列。现在我有一个唯一的键（时间戳和 AI），我可以使用命令“LAST_INSERT_ID”轻松获取当前插入的 id。是否可以每秒/有新时间戳时重置 AI 计数器？或者是否可以检测是否有相同时间戳的数据集并增加AI值（我仍然希望能够使用LAST_INSERT_ID）。

请分享一些想法。

【问题讨论】：

使用时间戳作为主键不是一个好主意 - 迟早会需要同时插入 2 行的情况，它会失败。 AI 始终是唯一的，将其用作您的 PK，但如果您需要经常在 WHERE 子句过滤器中使用它，请在时间戳上创建一个索引。
“由于性能原因，时间戳应该是整数而不是日期时间列。” -- 时间戳类型不正确，integer，将导致相反的结果。迟早您需要使用日期/时间算术进行查询，并且必须昂贵地转换时间戳才能使用内置函数和运算符。

标签： mysql performance auto-increment

【解决方案1】：

由于性能原因，时间戳应该是整数而不是日期时间列。

我认为您相信datetime 被存储为字符串。 It is stored as numbers 非常有效且范围更广，more accuracy 比整数。

使用整数可能降低性能，因为数据库可能无法正确索引它以用作时间戳。这会使查询复杂化，因为如果不先将整数转换为日期时间，您将无法使用完整的date and time functions。

使用适当的日期/时间类型，对其进行索引，然后让数据库对其进行优化。

此外，我不想在短时间内（两秒之间）限制数据量。因此，我想到了一个 [附加] AUTO_INCREEMENT 列。

这似乎违背了“保存一些列”的观点。现在你的主键是两个整数。更糟糕的是，它是一个 compound 键，它需要所有引用来存储这两个值，这会增加存储需求并让连接变得复杂。

确定下一个主键所需的所有额外工作可以在insert trigger 中完成，但现在您为每个插入增加了复杂性和额外工作。

使用时间戳作为我的主键是个好主意吗？

主键应该是 A) 唯一且 B) 不可变的。时间戳不是唯一的，您可能需要更改它。

您的主键不太可能成为性能或存储瓶颈。除非您有充分的理由，否则请坚持使用简单的、自动递增的大整数。一个很大的整数，因为 20 亿比你想象的要小。

MySQL 将其封装在serial 中，即bigint unsigned not null auto_increment unique。

【讨论】：

【解决方案2】：

TIMESTAMP 和 DATETIME 作为 PRIMARY KEY 是有风险的，因为 PK 必须是唯一的。

否则，可以将它们用于 PK 或索引。但这里有一些警告：

使用复合索引（多列）时，把=测试的东西放在前面；把日期时间放在最后。
选择 PK 时，越小越好。 TIMESTAMP 和 DATETIME 占用 5 个字节（不包括微秒）； INT 是 4 个字节； BIGINT 是 8。
将一个 PK 值与另一个进行比较所花费的时间是微不足道的。这包括角色 PK。例如，country_code CHAR(2) CHARACTER SET ascii 只有 2 个字节 - 比“规范化”它并用 4 字节 cc_id INT 替换它要好。
所以，不，不要费心使用 INT 而不是 TIMESTAMP。
根据我的经验，2/3 的表具有“自然”PK，不需要 auto_increment PK。
使用 auto_inc 最糟糕的地方之一是在多对多映射表上。它可能会使大多数操作减慢 2 倍。

你暗示PRIMARY KEY(timestamp, ai)：

您需要添加INDEX(ai) 才能让AUTO_INCREMENT 开心。
它为临时“近”行提供参考位置。但ai 本身也是如此。
不，没有实用的方法可以每秒重置 ai。（MyISAM 有这样的引擎，但不要使用那个引擎。）相反，请务必声明 ai 大到足以在溢出之前持续“永远”。
但我想不出没有更好方法的用例。

【讨论】：