Database 如何实现截断的sha1数据库密钥？

我正在开发一个多租户应用程序，它将实现服务API。出于安全原因和数据迁移/复制方面的考虑，我不想公开默认的自动增量密钥，因此我正在寻找其他密钥。GUID/UUID是一个明显的选择，但是他们让URL有点长，在阅读一篇关于他们的文章时，我看到Google使用“截断的SHA1”作为他们的URL ID

这是怎么回事？据我所知，您可以对部分/所有对象内容进行散列，以生成密钥。我的对象会随着时间的推移而改变，因此散列整个对象将无法工作，因为密钥需要随着时间的推移保持不变。我可以实现UUID并散列它们吗？对密钥使用SHA1有哪些限制/问题（例如最大记录、冲突等）

我一直在搜索谷歌，但没有找到正确的搜索查询

/*编辑：有关环境的更多信息*/

---

目前我们是一家Java商店，使用Spring/Hibernate，后面是MySQL。我们正在将核心开发切换到Grails，而Grails正是实现这一想法的地方。

这实际上是一个非常可靠的想法，尽管它可能会使键查找变得有点困难（我想，除非您对键进行散列并将其内联到表中）。你只需要对你使用的每一个键进行散列，不过如果你是自动递增的，那没问题。您甚至不需要GUID—您甚至可以将密钥散列，因为这是一个单向操作，不容易反转。您甚至可以在散列密钥之前对其“加盐”，这会使密钥变得不可预测，从而使其几乎不可破解

有一个关于冲突的问题，但是对于SHA1，您的哈希是160位，或者有1.46×10^48个唯一值，这应该足以支持许多唯一键中的一小部分，而不必担心冲突。如果您有足够多的密钥仍然担心冲突，那么可以升级到类似SHA256甚至SHA512的版本，这应该足够长，以避免任何合理的冲突担忧

---

如果你需要一些散列代码，发布你正在使用的语言，我可以找到一些，尽管如果你知道你在寻找什么，网上有很多可用的代码。

我不久前考虑过一个类似的问题，并最终实现了它。它不是超级安全的，但提供的URL比例如SHA256短得多，而且完全没有冲突。

经过更多的研发，我发现截断SHA哈希对我们不起作用。我们放弃了这个想法，转而生成一个更短的UUID。我们借用了Java（UUID）实现并创建了一个新类，该类生成可变长度的UUID，从而消除了散列它们的需要。