MySQL大十六进制索引

Question

[解决]

我第一次遇到了一个有相当大增长的数据库（ 125.000次插入/天）。

该数据库用于跟踪网络设备。

我有很多与这些设备相关的数据，我将在第2天更新它们（检查它们是否已升级/降级/更改位置/已卸载以及数千种东西）SO意味着我需要不断更新它们唯一固定的东西就是他们的序列号。

现在我的头痛开始......

我有一个无用的 ID [int（11）PK），它没用，因为我所做的一切都是基于 SerialNumbers [varchar（22）UQ]

进一步看，我看到序列号始终是（7到24）个地方的HEX，我脑子里的第一件事就是：TADA解决了，只是将那些序列号作为整数并且每次使用hex2dec转换工作没什么好看的......然后我想没有签名的bigints对于大于HEX（16）的数字来说不够。

最后，问题是：

  

任何人都知道哪种是最快的可索引存储方式   我的SerialNumber字段？

如果你没有尝试过你想说的解决方案，我不介意，任何想法都会受到欢迎和Upvoted :)

下图显示了数据库中每个SerialNumber长度的序列号数。

Answer 1

首先，检查时间。对这样一个短字符进行索引并不比索引64位整数慢得多。把你的序列作为PK。对于其他解决方案，您可以使用64位散列或串行（注意碰撞！），或将长串行分成2部分，并在两列上进行复合PK，我认为这将比串行上的简单索引慢。

Answer 2

也许这不是最好的方式，但对于这种情况至少就足够了：

使用serialnumber作为VARCHAR（25）PK（对于10.000.000.000选择，为414秒） 使用serialnumber作为CHAR（25）PK与LPAD（401秒为10.000.000.000选择）

在每次提交后简单地使用ANALYZE TABLE和OPTIMIZE TABLE之后，我去了赢家： 使用serialnumber作为VARCHAR（25）PK（10.000.000.000选择268.759秒）

BTW，还发现在我的表中使用小更新比只使用一个更快，因为： Currently one SQL statement runs from start to end in the same physical thread.