MySQL 不可猜测的整数主键
我正在开发一个使用整数作为多个表的主键的数据库。我想让主键相对难以猜测——它们不需要太紧，只是不增加低几百个整数即可。由于我正在使用现有数据将其改造到现有模式中，因此更改主键（整数）的数据类型是不可行的。我想知道如何最好地生成 ID。到目前为止，我可以想到这些选项：
- 使用
UUID()生成 UUID 并将其转换为整数。 - 保留一个充满随机整数的单独表，并使用一个过程从事务内的表中选择和删除一个。
- 使用 UNIX 时间戳，加上随机的 n 位数字，例如
CONCAT(UNIX_TIMESTAMP(),SUBSTRING(RAND() FROM 3 FOR 6))
我也愿意接受其他建议。
如果您能提供任何想法，我将不胜感激。
谢谢， 罗斯
I'm working on a database that uses integers as primary keys for a number of tables. I'd like to make the primary keys relatively difficult to guess — they needn't be super-tight, just not incrementing integers in the low hundreds. Since I'm retrofitting this into existing schemata, with existing data, changing the datatype of the primary key (integer) is not feasible. What I'm wondering is how best to generate the IDs. So far, I can think of these options:
- Generate UUIDs using
UUID()and convert them to integer. - Keep a separate table full of random integers and use a procedure to select and delete one from the table inside a transaction.
- Use the UNIX timestamp, plus a random, n-digit number, e.g.
CONCAT(UNIX_TIMESTAMP(),SUBSTRING(RAND() FROM 3 FOR 6))
I'm open to other suggestions, too.
I'd appreciate any thoughts you can offer.
Thanks,
Ross
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你为什么要这么做？你会弄乱数据的物理存储方式。如果需要通过 URL 传递进行查找，请使用辅助索引并将其设为 GUID。
Why are you doing that? You'll mess up the way the data is physically stored. Use secondary index and make it a GUID if you need to pass it trough URLs for lookups.