是否应为用于生成API密钥的UUID列添加唯一约束？

绝对值得——而且我强烈建议你这么做，哪怕UUID理论上的冲突概率低到可以忽略不计。下面是几个关键原因：

• 防代码层面的意外错误：UUID算法本身靠谱，但生成UUID的代码可能出问题——比如不小心重复使用了随机种子、依赖的库有bug、甚至是业务逻辑里误把同一个UUID批量插入了。唯一约束会在数据库层面直接拦截这些错误，避免脏数据流入系统，比在应用层做校验更可靠（毕竟应用层可能有多个实例，分布式场景下校验成本更高）。
• 明确数据语义：给UUID列加上唯一约束，相当于给数据库和未来维护代码的开发者一个清晰的信号：「这个字段的值是全局唯一的，它是资源的唯一标识」。这能避免后续有人误修改逻辑，比如取消应用层的UUID唯一性校验，或者不小心把非唯一值插入进来。
• 性能开销可以忽略：现代关系型数据库（比如PostgreSQL、MySQL）对唯一索引（唯一约束会自动创建对应的唯一索引）的性能开销极小。哪怕是字符串类型的UUID，只要你的数据量不是极端庞大，索引的维护成本完全在可接受范围内。反而如果没有约束，哪天真出现重复值，排查和修复的成本会高得多。
• 应对极端场景：虽然UUIDv4的冲突概率低到「你连续中好几次彩票都比这概率高」，但如果你的业务未来会扩张到千亿级数据量，唯一约束能帮你提前发现冲突，而不是等到API密钥重复导致业务故障才去排查。

另外补充一句：如果担心UUID作为索引的性能问题，可以考虑使用UUIDv7（带时间戳的有序UUID），它能让索引的插入更高效，但唯一约束依然是必不可少的。

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