如果你在数据库场景里用「生成随机值→查重→重复就重试」的方式来生成UUID类的唯一标识，可得小心了——这种实现藏着两个棘手的问题：

• 碰撞概率飙升的性能瓶颈
  当可用标识的占用率达到50%时，每次生成随机值的碰撞概率直接升到50%。这意味着你可能要重试好几次才能拿到一个可用的ID，系统性能会断崖式下跌。

• 理论上的无限循环风险
  不管当前占用率有多低，这种方案的最坏情况都是无限循环。虽然初期出现的概率极低，但理论上存在程序一直生成已被占用的数值、陷入死循环的可能。而且随着可用标识被不断占用，这种情况发生的概率会越来越高。更头疼的是，这种Bug极难排查——它不是必现的，可能上线几个月才偶尔触发，定位起来非常麻烦。

其实标准UUID（比如UUIDv4）的设计初衷就是通过足够大的随机空间来把碰撞概率降到可以忽略的程度，完全不需要做这种事后查重的操作。如果你的场景对唯一性要求极高，也可以考虑用带时间戳的UUID版本（比如UUIDv1），或者结合数据库自增序列+随机前缀的方式，从根源上避免这种重试查重的尴尬。

内容的提问来源于stack exchange，提问作者Muhammad Umer