用于MySQL Char()或其他字段的顺序UID集生成

Question

试着用谷歌搜索但是：

问题：外部为MySQL字段生成顺序UID值的最佳方法，该字段必须表示为字符串。

原因：

通用顺序UUID-ish值，用于磁盘上订单/页-附加插入，以执行写入和日期前缀的读取速度时，搜索一个索引的字段从前。该列将被索引，但寻找最好的数据，以提高索引读和表写入性能，而不是一个简单的老UUID。

我最初的想法是在固定宽度的char字段中添加或替换UUIDv4生成的字符串(即[Unix epoch][remaining UUID4] )的某些粒度(可能是填充的时代)，但我不确定这是否会有所需的页面/磁盘排序结果和索引搜索结果。一个例子是：

12904645950049bceba1cc24e80806dd

这些值必须独立于MySQL本身，因此使用UUID和时间戳而不是自动递增的某些变化。

任何知道MySQL索引内部结构的人都有任何建议(对于InnoDB表)吗？

艾登

Answer 1

可能有点离题，但请看一下推特的雪花。他们说是：

• (大致)时间排序(有助于避免昂贵的随机主键BTREE更新)
• 直接可排序
• 紧致

更不用说其他功能(HA等)。你既可以破解他们的算法，也可以按原样使用。

整个UID只占用64位空间，所以我想索引是非常有效的--参见http://www.mysqlperformanceblog.com/2006/10/03/long-primary-key-for-innodb-tables/ (一个反例)。

Answer 2

我认为您可能需要更具体地处理您想要解决的问题(实际问题是什么--为什么不是auto_increment?，您建议的模式是什么?等等)。要回答你的内心问题：

• InnoDB将数据存储在16K页的索引(聚集索引)中。

不按顺序插入的风险至少有两倍：

1. 如果没有合适的内存，则可能需要执行随机IO操作，从磁盘加载页以将值插入到该页。
2. 页面中可能没有剩余的空间(InnoDB填充了93%，并为更新留下了很小的空白)，这可能导致页面需要被分割。更多的拆分页=碎片/内存等事情的不太理想的使用。

因此，我认为只要您是大致顺序的，至少(1)对主键索引(对于任何唯一的索引仍然是正确的)并不关心。你只需要担心(2)。

我之所以说理解这个问题很重要，因为除了长GUID之外，还有很多方法可以做到这一点。首先，MySQL中的BIGINT比您可能使用的任何数据类型都要小，但其范围为18个五分之一。您可以一次将密钥空间N，000的“块”分配给工作节点，并保证不重复。如果一个工作节点崩溃了，并且没有使用它分配的所有块，那又怎样？无所谓。

Answer 3

看看这个问题。它可能没有详细说明MySQL索引的具体用途，但它确实提供了一些性能数据，以及生成Seq的代码。UID。

MySQL索引似乎极大地受益于顺序ID，根据MySQL，索引依赖于磁盘排序(参见节:B树索引特性)来找到相关的结果。

从内存中，MySQL索引(至少对于字符串索引)首先依赖于字段的字母数字排序，即“哦，从A开始?我有以A开头的数据，我会给你拿来……等等。”而不是对每个字段进行全文扫描。

并且按顺序输入UID意味着索引不会首先重新排序结果‘字母顺序’，或者至少大大减少了这一时间，因此上面提到的性能优势。

(不是真正的解决方案，但至少是一个答案。)