寻找MySQL替代主键“auto increment”作为插入查询的时态信息表

我有一个表格，每天输入许多临时项目

它有时会变得很糟糕，主键的增量高达10k

由于大多数时间临时项都被删除，我不认为有理由将主键保持在这么高的数字

我要寻找的是一种创建查询的方法，其中下一个插入的行键号将是下一个可用的最小ID

---

我知道如何使用服务器端代码。

1可以找到最小的未使用id，但我不确定该id是否符合要求，例如，另一个选项是与现有表联接

set @rowid = 0;
SELECT rowid FROM
(select @rowid := @rowid + 1 as rowid 
from TABLE) rowids
left join TABLE ON (rowid = ID)
WHERE ID is null
ORDER BY rowid limit 1;

2您还可以维护一个免费可用ID表

---

3此外，您可以将记录标记为已删除，而不是删除记录，然后重新使用这些记录。

即使间隔为10k，使用BIGINT无符号类型仍然可以存储近200万条记录。。。所以第一个问题是：这有关系吗？第二个问题是，如果真的有一些有效的理由来避免空白，为什么不在MYSQL中设置一个时间戳类型字段作为PK或TIMESTAMP6>=5.6.4，如果您想要微秒的精度呢？如果有一些合理的理由可以避免间隙和时间戳PK，为什么要删除这么多记录？也许您可以更改体系结构，以便仅在需要永久性时才将记录插入表中？我保存的记录是临时的。如果满足某些方面，则会将它们转移到常量记录表中。我不会使用BIGINT或TIMESTAMP，因为它需要更多的空间并降低整体性能。因此，我希望它的数量少，容量小，搜索结果更快。您似乎混淆了许多问题：空间和性能通常是负相关的。存储预处理结果所消耗的空间越多，例如索引树，读取操作的速度就越快；除此之外，时间戳需要4字节的存储空间-与INT相同。此外，标称值与整数消耗的存储空间无关，尽管BIGINT确实比INT使用更多的存储空间，但是所有现代计算机的CPU字大小和数据总线宽度都是64位的，因此唯一真正的区别在于磁盘存储和IO。无论如何，为什么不在常量记录表中生成PK并完全避免这个问题呢？如果我想INT，如果我使用的是64位操作系统，您的参数是有效的。事实并非如此。我将尝试向您描述这种情况：人们互相发送MSGE，例如whatsapp，您希望将MSGE存储在一个临时表中，直到本应接收这些MSGE的用户联机并获得它，然后您要么删除临时记录，要么将其传输到常量表中。问题是大多数MSGE都是临时的，只有几秒钟的时间，而且可能会有许多MSGE同时发送到服务器，因此我希望尽可能降低阈值。1如何？2太消耗了。在最坏的情况下，SELECT可能需要遍历所有表。我添加了一个示例。如果可用，使用现有表进行联接是更好的选择。如果你使用索引，我不认为3有什么大问题，事实上，标记删除而不是真正的删除应该更有效。这是FAT中使用的一种技术。你实际上是非常正确的！我已经进行了一些性能测试，显然不仅tinyint没有真正影响我的空间。。这也节省了我删除行和创建新行的时间。我刚刚更新了第一个删除的，它几乎快了10%。可爱！谢谢你的反馈