组成一个随机的字符串。
尝试插入带有 UNIQUE 约束。
如果插入，则标识符是您的。
如果复制失败，请返回步骤1。
如果你有一个足够长的字符串和一个足够健壮的随机数生成器，那么碰撞应该是很少的。如果你使用所有的字母（大写/小写）和数字，那么你就可以得到大约20个字符的符号，这些符号不太可能发生冲突。
键越短越好，但碰撞会越频繁。自己测试一下，生成几百万个密钥，看看平均需要多少次重试。

随机字符串不必是主键。你可以有一个 AUTO_INCREMENT 主键，在其他表中用作外键。此外，你可以有一个 unique_id 包含在URL中公开的随机字符串的列。这可以有一个唯一的索引，这将使查找效率。
这类似于用户表，其中可能有一个顺序表 user_id ，也是独一无二的 user_name 用于登录、发送消息、在帖子中显示等的列。
对于 unique_id 列中，最好使用哈希索引，而不是b树索引。不幸的是，在mysql中，这只在 MEMORY 存储引擎，不是 InnoDB 或者 MyISAM .

到目前为止的讨论是关于uuid有多糟糕。虽然我同意，但我认为这在这里不适用。
您的情况是：给定一个看起来随机的id，获取它引用的一条记录。对的？您不必担心获取几个“连续”记录。
生成随机密钥：uuid相当庞大；你可能想要短一点的。采取 MD5() 一些独特的字符串-也许 AUTO_INCREMENT id与秘密种子连接。然后转换为base64，这样就不会太长(警告：小心那些可能会弄乱url的特殊字符。
获取：使用该键作为 PRIMARY KEY 或者 UNIQUE 关键会以随机性的方式付出代价。但我怀疑这只是你应用程序开销的一小部分。