[已解决]
我第一次遇到一个增长相当大的数据库(125.000 次插入/天)。
该数据库用于跟踪网络设备。
我有很多与这些设备相关的数据，我会每天更新它们(检查它们是否升级/降级/改变位置/卸载以及数千个东西)所以意味着我需要不断更新它们，并且唯一的固定的事情是他们的序列号。
现在我开始头痛了......
我有一个无用的ID [int(11) PK)，它没有用，因为我所做的一切都是基于SerialNumbers [varchar(22) UQ]。。 p>
进一步观察，我发现序列号始终是从(7到24)位的十六进制，我想到的第一件事是:TADA解决了，只需将这些序列号作为整数，然后每次都进行十六进制到十进制转换，没什么花哨的......然后我想发现对于大于 HEX(16) 的数字，无符号 bigint 是不够的。
最后，问题是:
Anyone have any idea about which is the fastest indexable way to store my SerialNumber fields?
如果您没有尝试您要说的解决方案，我不介意，任何想法都将受到欢迎并投票:)
下图显示了数据库中每个序列号长度的序列号计数。
最佳答案
首先，检查时间。对如此短的字符进行索引并不比对 64 位整数进行索引慢多少。把你的序列号设置为PK。对于其他解决方案，您可以使用 64 位哈希或序列(注意冲突!)，或者将长序列分成 2 部分，并在两列上进行复合 PK，我认为这会比序列上的简单索引慢。
关于MySQL 大十六进制索引，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/32901545/