问题描述
我正在考虑为我的数据编制索引的最佳方式。使用时间戳作为我的主键是个好主意吗？无论如何我都在保存它，我想保存一些列。由于性能原因，时间戳应该是整数而不是日期时间列。此外，我不想在短时间内（两秒之间）限制数据量。因此，我想到了一个额外的 AUTO_INCREMENT 列。现在我有了一个唯一的密钥（时间戳和 AI），我可以使用命令“LAST_INSERT_ID”轻松获取当前插入的 ID。是否可以每秒/当有新的时间戳时重置 AI 计数器？或者是否可以检测是否有相同时间戳的数据集并增加AI值（我仍然希望能够使用LAST_INSERT_ID）。
请分享一些想法。
解决方法
出于性能考虑，时间戳应该是整数而不是日期时间列。
我认为您相信 datetime 存储为字符串。 It is stored as numbers 非常有效，范围更广，more accuracy 比整数更宽。
使用整数可能会降低性能，因为数据库可能无法正确索引它以用作时间戳。这会使查询复杂化，因为如果不先将整数转换为日期时间，您将无法使用完整的 date and time functions 套件。
使用适当的日期/时间类型，对其进行索引，然后让数据库对其进行优化。
此外，我不想在短时间内（两秒之间）限制数据量。因此，我想到了一个 [额外的] AUTO_INCREEMENT 列。
这似乎违背了“保存一些列”的意义。现在你的主键是两个整数。更糟糕的是，它是一个复合键，它要求所有引用都存储这两个值，从而增加了存储要求并使连接复杂化。
确定下一个主键所需的所有额外工作都可以在 insert trigger 中完成，但现在您为每个插入增加了复杂性和额外工作。
使用时间戳作为我的主键是个好主意吗？
主键应该是 A) 唯一和 B) 不可变的。时间戳不是唯一的，您可能需要更改它。
您的主键不太可能成为性能或存储瓶颈。除非你有充分的理由，否则坚持使用一个简单的、自动递增的大整数。一个大整数，因为 20 亿比你想象的要小。
MySQL 将其封装在 serial 中，即 bigint unsigned not null auto_increment unique。
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足够大，以便在溢出之前“永远”持续。 - 但我想不出没有更好方法的用例。