Web PK，自动增量与 UUID 风格，哪个更好，为什么？
自动增量和 UUID 风格之间的真正区别是什么？
我认为 auto inc 与 uuid 相比很容易被破解，
在有很多记录的查询中，Uuid 比自动增量慢，但是它有很大的区别吗？
What is the real difference between autoincrement and UUID style?
I think auto inc is easy to hack vs uuid
Uuid is slower than autoincrement in a query with to many records, but is there a huge difference in it?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
从关系模型的角度来看，主键非常重要，
PK 越小越好。这就是为什么数字 PK 是最好的。
如果您担心它很容易被“破解”，您可以添加一个额外的 UUID 作为自然键，
这就是我在几个项目中看到的它就像一个魅力。
The primary key is very important from point of view of relational model
The smaller the PK, the better. That's why numeric PK is the best.
If your concern is that it's easy to "hack", you can add an additional UUID as a natural key
That's what I've seen in a couple of projects and it worked like a charm.
增量 ID 本身并不“容易破解”，它只是提供了当您使用大随机 ID 时被遮盖（但并非完全隐藏）的入口点。仍然需要有糟糕的实施和可利用的软件才会存在真正的危险。正如您在地址栏中的 URL 中所看到的，该站点使用增量 ID 没有任何问题。
不过，除了安全考虑之外，当您不希望用户轻易猜测其他（尽管是公共）内容的 URL 时，随机唯一 ID 有时会很有帮助。例如，在房地产网站上，您可能不希望提供在 ID 中“上下”查看竞争对手条目的可能性，即使他们可以通过搜索找到所有条目。一点阻碍可能是一件好事。
为什么不两者都使用呢？用于加快索引和关系速度的数字自动递增键；用于外部访问的随机 UID。
An increment ID is not "easy to hack" in itself, it just provides entry-points that are obscured (but not entirely hidden) when you use a big random ID. There still needs to be badly implemented and exploitable software for there to be a real danger. As you can see in the URL in your address bar, this very site uses incremental IDs with no problems.
Apart from security thoughts though, a random unique ID is sometimes helpful when you don't want users to easily guess the URL of other (albeit public) content. For example, on a real estate site, you may not want to offer the possibility of going "up and down" in the IDs, looking at competitors' entries, even though they could find them all through searching. A bit of obstruction might be a good thing.
Why not use both? A numeric auto-increment key for speed in indexing and relations; a random UID for outside access.
一些想法：
some thoughts:
请注意 PK 列的长度...UUID 和 GUID 是非常长的...字符串。
INT 甚至 BIGINT 自动增量列可以确保在更小的空间中的唯一性。
请注意，自动增量列在表管理方面有一些自己的问题。如果您截断/删除创建表，那么自动增量将很难维护。
另外，MySQL 中单个表只允许有 1 个自增列。
如果您的数据允许，请使用从数据派生的某种哈希来进行索引和性能。
Take care of the LENGTH of your PK column... UUIDs and GUIDs are extremely long... strings.
An INT or even BIGINT autoincement column can ensure uniqueness in a much smaller space.
BEWARE that autoincement columns have a few issues of their own around table management. If you truncate/drop-create tables then an auto-increment will be hard to maintain.
ALSO, only 1 auto-increment column in MySQL is allowed for a single table.
If your data allows it, use some kind of HASH derived from the data for indexing and performance.