我们有一个包含 1000 万条记录的数据库表。我们不想使用 auto_increment，因为这会让我们的用户知道我们有多少记录。我们不想将其暴露给我们的竞争对手。我看到的问题是使用 UUID 或类似的东西会降低查询性能。
例如，这是一个禁忌： http ://domain.com/widgets?id=34345
因为竞争对手可以抓取网站以确定我们有多少小部件。这种业务屏蔽应该在app层面处理，还是在数据库层面处理好？大多数人在这种情况下会怎么做？我们使用的数据库是 postgres，但我认为该解决方案仍然与数据库无关。
使用 GUID 作为键。您可以查看此问题以了解为什么可以这样做。您可能可以使用 GUID 编号的子集来逃避，但位大小越小，冲突的可能性就越大。GUID 不会太大，应该可以存储为数字。密钥的转移将是密钥的 4 倍，但这在很大程度上是无关紧要的。
对于 1000 万行，存储空间可能多出大约 120 MB，但在如此大的大小下似乎可以忽略不计。您是否测试过 GUID 的性能并发现它们缺乏？
我使用基于 slug 的 url，slug它是唯一的，因此是索引字段，而且你会得到很好的 url，比如http://example.com/awesome-blue-widget。您可以通过小写小部件名称、用连字符替换空格等来创建 slug。我的 web 框架有一个简单的slugify功能，如果已经使用了 slug，我将其扩展为在末尾添加一个增量。
蛞蝓通常与模式相匹配[a-z0-9-]+。而且您仍然可以将自动递增的主键用于其他表等中的外键，而不会影响您的业务数据。