一般用户表的用户 ID，是不是设计成字符串的比较多
source link: https://www.v2ex.com/t/920125
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
 |
Chad0000 10 小时 34 分钟前 via iPhone 整型自增。
放心，系统下线了用户都不会有那么多。 |
 |
zoharSoul 10 小时 31 分钟前 不是, 基本都是整形
|
 |
shyangs 10 小时 25 分钟前 別和百度貼吧踩同一個坑。
哪天產品拍腦袋, 說百度帳號(用戶名)要可以讓使用者自由地更名, 你要學貼吧在 username 裡加各種符號避免重複? |
|
shyangs 10 小时 21 分钟前 承上，所以區分 id 和 name,
id 用整型自增，系統決定，使用者不可更改 id ，只能改 name 。 |
2 |
justfindu 10 小时 19 分钟前 自增, 如果你要避免被扫, 那就 uuid 呗
|
 |
op351 10 小时 19 分钟前 因为用主键的整型自增列会暴露其他用户，所以不会用主键的整型自增列
而是自增列之外设计一个单独的用户 ID 列 使用三方库根据日期之类的生成不会重复的字符串 |
 |
xiaoliu926 10 小时 11 分钟前 @op351 我这边的项目都是雪花算法生成主键 id 的,安全的很
|
 |
LeegoYih 10 小时 7 分钟前 bigint
实际接口都会鉴权，不存在通过 ID 被暴力遍历的情况 |
|
op351 10 小时 1 分钟前 |
 |
NoKey 9 小时 58 分钟前 有时候对外叫 userID ，他实际不是 id ，用户 id ，要区分业务层面的 id ，和数据层面的 id ，你讲的是哪一个？😆
|
 |
chendy 9 小时 50 分钟前 自增，怕被爆破就在接口层加一层编码规则处理，变成火星文（比如加上固定前后缀然后取字节然后翻转然后 base64 啥的）
|
 |
superedlimited 9 小时 46 分钟前 为什么 mongodb 自动生成的_id 是一串字符串呢
|
 |
abelyao 9 小时 46 分钟前 已经习惯了能用 uuid 就用 uuid 了，或者 nanoid - https://github.com/ai/nanoid
|
 |
god7d 9 小时 44 分钟前 via iPhone |
 |
melkor 9 小时 44 分钟前 via iPhone 用自增 ID 的这些建议，不考虑横向 sharding 问题吗？雪花生成全局唯一 ID 就行了
|
 |
fiypig 9 小时 42 分钟前 我第一家公司就用字符串的 用户账号， 现在的用自增，也有用 UUID ，我还没遇到过。。
|
 |
manasheep 9 小时 41 分钟前 无脑 GUID （ UUID ）就可以了，MongoDB 的话用它自己的 ObjectID 也行
|
 |
dk7952638 9 小时 40 分钟前 id 是给系统用的编码，no 是给人用的编码
id 最好是自增，如果是分布式可以用雪花算法，自增可以提高数据库性能，还能实现游标分页 no 一般都是有意义的，比如快递单号 |
 |
tool2d 9 小时 38 分钟前 爆破很好处理的，你 api 加密一下就可以了。或者加个一次性访问权限，nonce 那种参数。
只要索引建的好，字符串查找速度也不慢的。 |
|
LeegoYih 9 小时 31 分钟前 @superedlimited MongoDB 的 ObjectId 也是根据 Timestamp 和 MachineID 自增的 bigint ，只不过它是 12 字节 96 位的整数，用字符串方便展示
|
|
superedlimited 9 小时 23 分钟前 @LeegoYih #21 谢谢，我查了一下文档，原来它是 16 进制的数字。我是直接用的 mongodb 的免费 cloud 数据库，还没仔细看文档。
|
 |
vitoliu 9 小时 20 分钟前 BIGINT 毋庸置疑，具体生成规则，看用户 ID 包含不包含对外业务含义，包含对外业务含义生成规则不能包含趋势递增。
|
 |
xuanbg 9 小时 18 分钟前 我选择雪花 ID 。用字符串是什么鬼？ UUID ？
|
|
Chad0000 8 小时 46 分钟前 |
 |
acvrock 8 小时 40 分钟前 BIGINT +1,UID 大概率是其他业务表的索引,越短越好,最好趋势递增
但是不能简单的自增,否则用户规模会被外部猜测出来,或者被扫描爆破 |
 |
pkoukk 8 小时 36 分钟前 内部系统用数据库自增
对外系统用雪花，UUID 太长了，占存储太多了，而且最主要的坑是如果拿 uuid 当主键，插入性能太差了 虽然用户不太可能用户注册有太高并发，但是如果你需要用备份恢复一个库或者增加一个从库的时候就要疯 |
 |
allinoneok 8 小时 25 分钟前 如果你的 ID 需要写入 cookie 并加密就选择随机生成 id
|
 |
RICKEYGONG 8 小时 8 分钟前 Guid userId = new Guid();
|
 |
leeraya 8 小时 2 分钟前 bigint 够够的
|
 |
b821025551b 8 小时 2 分钟前 @melkor 雪花成本应该是最高的，在大部分引擎下，无序主键会导致查询性能降低，以及空间浪费
|
 |
youisme 7 小时 58 分钟前 @b821025551b 雪花算法是有序的
|
 |
afstyle 7 小时 52 分钟前 @b821025551b 建议你好好看看雪花 id 算法
|
 |
Ashore 7 小时 47 分钟前 via Android 你离职了以后都不会有那么多的用户的。放心吧
|
 |
cnbattle 7 小时 44 分钟前 推荐雪花 id ， 需要注意的数 如果前端是 js ，json str 转 json 对象 数字 大于 17 位时会丢失精度 得前端或后端特殊处理下
|
 |
karloku 7 小时 41 分钟前 字符串的索引性能不行, 作为主键还是用整型好
不管是 mongodb 的 ObjectId 还是 UUID 本质上也只是被表示为 16 进制的定长 bits, 在数据库里可以用 binary(12) 或者 binary(16) 存取. mysql8 里有直接用于转换字符串的函数 `UUID_TO_BIN()` / `BIN_TO_UUID()` 和生成用的 `UUID()` . postgres 则是直接支持 uuid 类型的字段, 支持在 sql 里用字符串进行写入和查询. 不需要满足可排序性的时候可以用 uuidv4. 需要满足可排序性的时候可以用 mongodb 的 ObjectId 和 128 位的 ulid. |
 |
litchinn 7 小时 39 分钟前 准确来说，雪花算法那个叫单调递增。
参与的有一个项目，最开始是自增，但是后面有个客户有个需求，他部署了两套系统，A 、B ，但是每天要将 B 系统的数据全部同步到 A ，然而这些数据里有关联 id ，于是只能改成雪花算法生成的 id ，bigint 也用过字符串类型的 id ，但是因为没办法单调递增且自己 debug 很不方便所以个人并不喜欢 目前使用雪花算法 id ，数据库 bigint 并且设置自增 |
 |
BeforeTooLate 7 小时 21 分钟前 整数自增问题用户容易被爬虫遍历吧，比如你是 id1 ，我是 2 ，只要一个个试过去就行了
|
 |
liuidetmks 6 小时 42 分钟前 @BeforeTooLate 不成熟的想法，自增一个比较大的素数就行了。uint64 溢出也不要紧，正好相当于取模了
|
 |
realpg 6 小时 36 分钟前 unsigned uint64 自增
多库分布系统就他自己自增 然后复合唯一索引带 node_id ，合并一起做 userid |
|
realpg 6 小时 35 分钟前 |
 |
Danfi 6 小时 31 分钟前 via Android 数据库查询用 bigint ，对外输出 hashid
|
 |
hulala1021 6 小时 24 分钟前 职业生涯遇到过好几次数据库迁移，得到的教训就是数据库尽量不要用自增 id ，不然迁移表数据简直是灾难
|
 |
polo3584 5 小时 57 分钟前 区分 uid 和 uname 就行
|
 |
zzzzz001 3 小时 16 分钟前 @BeforeTooLate 平时写接口注意点，带上当前登录人的标记去数据库查，只查当前登录人的信息，不就避免被刷了吗。这样的思路很多
|
 |
ccagml 3 小时 8 分钟前 via Android 用户 id 直接数据库自增？都不分表的吗？
|
 |
jobmailcn 3 小时 2 分钟前 整型自增，对外加密，就像微信的 openid 一样，虽然不清楚具体实现，但应该是可以解密得到整型自增 uid 的
|
 |
hsuyeung 1 小时 24 分钟前 via iPhone bigint ，然后对外 hashid
|
 |
wangritian 1 小时 3 分钟前 用了很多年 uuid ，完全代替了自增数字，并且封装在所有使用过的框架中
除了一点点性能问题，好像没什么缺陷了吧 |
 |
zhaogaz 43 分钟前 看需求吧。。
首先看你这个用户 id 定义成什么，还有就是个人习惯，公司习惯，代码项目习惯啥的。 有的是 us-xxxxx ；有的是 uuid ；有的是自增数；有的是长整数，这和 是不是字符串都没关系。。。 你想问的是数据库的实现，和 用户 id 设计没啥关系。。数据库层面，一般用 固定 char 就行。。你数据库存成数字有什么优势么？你想一想 然后再解释下自增 id：自增 id 相当于把 id 生成的事情扔到 db 了。看你们个人习惯和项目习惯，不是不可以。如果数据关联的逻辑也扔给 db ，这么做都没啥问题。 其实都挺新手的问题，大概能猜到 op 工作环境。 |
 |
twofox 17 分钟前 无脑雪花主键啊。。UUID 不建议，太长和分散，不适合索引
|
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK