一般用户表的用户 ID，是不是设计成字符串的比较多

整型自增。

放心，系统下线了用户都不会有那么多。

不是, 基本都是整形

和百度吧踩同一坑。

哪天品拍袋, 百度(用名)要可以使用者自由地更名, 你要吧在 username 加各符避免重?

承上，所以分 id 和 name,

id 用整型自增，系定，使用者不可更改 id ，只能改 name 。

自增, 如果你要避免被扫, 那就 uuid 呗

因为用主键的整型自增列会暴露其他用户，所以不会用主键的整型自增列
而是自增列之外设计一个单独的用户 ID 列 使用三方库根据日期之类的生成不会重复的字符串

@op351 我这边的项目都是雪花算法生成主键 id 的,安全的很

bigint
实际接口都会鉴权，不存在通过 ID 被暴力遍历的情况

@xiaoliu926
不用整型自增就行
我也是之前用 fiddler 分析某 app 的接口才意识到直接使用自增会导致用户信息泄露-。-

有时候对外叫 userID ，他实际不是 id ，用户 id ，要区分业务层面的 id ，和数据层面的 id ，你讲的是哪一个？

@NoKey 上面都提到了，主要怕被看出规则，我目前有个项目是用自增做关联字段，另外弄个字段+随机字符串作为用户唯一 ID ，总感觉很奇怪

自增，怕被爆破就在接口层加一层编码规则处理，变成火星文（比如加上固定前后缀然后取字节然后翻转然后 base64 啥的）

为什么 mongodb 自动生成的_id 是一串字符串呢

已经习惯了能用 uuid 就用 uuid 了，或者 nanoid - https://github.com/ai/nanoid

guid

用自增 ID 的这些建议，不考虑横向 sharding 问题吗？雪花生成全局唯一 ID 就行了

我第一家公司就用字符串的 用户账号， 现在的用自增，也有用 UUID ，我还没遇到过。。

无脑 GUID （ UUID ）就可以了，MongoDB 的话用它自己的 ObjectID 也行

id 是给系统用的编码，no 是给人用的编码
id 最好是自增，如果是分布式可以用雪花算法，自增可以提高数据库性能，还能实现游标分页
no 一般都是有意义的，比如快递单号

爆破很好处理的，你 api 加密一下就可以了。或者加个一次性访问权限，nonce 那种参数。

只要索引建的好，字符串查找速度也不慢的。

@superedlimited MongoDB 的 ObjectId 也是根据 Timestamp 和 MachineID 自增的 bigint ，只不过它是 12 字节 96 位的整数，用字符串方便展示

@LeegoYih #21 谢谢，我查了一下文档，原来它是 16 进制的数字。我是直接用的 mongodb 的免费 cloud 数据库，还没仔细看文档。

BIGINT 毋庸置疑，具体生成规则，看用户 ID 包含不包含对外业务含义，包含对外业务含义生成规则不能包含趋势递增。

我选择雪花 ID 。用字符串是什么鬼？ UUID ？

@melkor
有太多系统到废弃那天用户到不了那么多。自增没什么不好。

@chendy
@cjbi
@op351

有种叫 hashid 的技术你可以了解一下，安全起见你还可以将数组化[id, randomId]这样，第 1 个是真正的 Id ，后面那个是验证码。

BIGINT +1,UID 大概率是其他业务表的索引,越短越好,最好趋势递增
但是不能简单的自增,否则用户规模会被外部猜测出来,或者被扫描爆破

内部系统用数据库自增
对外系统用雪花，UUID 太长了，占存储太多了，而且最主要的坑是如果拿 uuid 当主键，插入性能太差了
虽然用户不太可能用户注册有太高并发，但是如果你需要用备份恢复一个库或者增加一个从库的时候就要疯

@Chad0000 学习了，原来有现成的东西可以用

如果你的 ID 需要写入 cookie 并加密就选择随机生成 id

@Chad0000 直接用雪花成本也不算高，关键是一旦要 sharding 那就很痛苦了，成本太高

Guid userId = new Guid();

bigint 够够的

@melkor 雪花成本应该是最高的，在大部分引擎下，无序主键会导致查询性能降低，以及空间浪费

@b821025551b 雪花算法是有序的

@b821025551b 建议你好好看看雪花 id 算法

你离职了以后都不会有那么多的用户的。放心吧

推荐雪花 id ， 需要注意的数 如果前端是 js ，json str 转 json 对象 数字 大于 17 位时会丢失精度 得前端或后端特殊处理下

字符串的索引性能不行, 作为主键还是用整型好

不管是 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.

准确来说，雪花算法那个叫单调递增。
参与的有一个项目，最开始是自增，但是后面有个客户有个需求，他部署了两套系统，A 、B ，但是每天要将 B 系统的数据全部同步到 A ，然而这些数据里有关联 id ，于是只能改成雪花算法生成的 id ，bigint
也用过字符串类型的 id ，但是因为没办法单调递增且自己 debug 很不方便所以个人并不喜欢
目前使用雪花算法 id ，数据库 bigint 并且设置自增

整数自增问题用户容易被爬虫遍历吧，比如你是 id1 ，我是 2 ，只要一个个试过去就行了

@BeforeTooLate 不成熟的想法，自增一个比较大的素数就行了。uint64 溢出也不要紧，正好相当于取模了

unsigned uint64 自增
多库分布系统就他自己自增 然后复合唯一索引带 node_id ，合并一起做 userid

@BeforeTooLate
数据库 ID 和前端显示 ID 为什么要统一？
发送前和获取后过一个 o(n)复杂度的简单变换，别人不知道算法就完事

数据库查询用 bigint ，对外输出 hashid

职业生涯遇到过好几次数据库迁移，得到的教训就是数据库尽量不要用自增 id ，不然迁移表数据简直是灾难

区分 uid 和 uname 就行

@BeforeTooLate 平时写接口注意点，带上当前登录人的标记去数据库查，只查当前登录人的信息，不就避免被刷了吗。这样的思路很多

用户 id 直接数据库自增？都不分表的吗？

整型自增，对外加密，就像微信的 openid 一样，虽然不清楚具体实现，但应该是可以解密得到整型自增 uid 的

@ccagml 分库分表也可以自增呀，例如百库十表，取 uid 低 10 位标识在哪个表，右移 10 位得到在具体表中的自增 id

bigint ，然后对外 hashid

用了很多年 uuid ，完全代替了自增数字，并且封装在所有使用过的框架中
除了一点点性能问题，好像没什么缺陷了吧

看需求吧。。

首先看你这个用户 id 定义成什么，还有就是个人习惯，公司习惯，代码项目习惯啥的。

有的是 us-xxxxx ；有的是 uuid ；有的是自增数；有的是长整数，这和 是不是字符串都没关系。。。

你想问的是数据库的实现，和 用户 id 设计没啥关系。。数据库层面，一般用 固定 char 就行。。你数据库存成数字有什么优势么？你想一想

然后再解释下自增 id：自增 id 相当于把 id 生成的事情扔到 db 了。看你们个人习惯和项目习惯，不是不可以。如果数据关联的逻辑也扔给 db ，这么做都没啥问题。

其实都挺新手的问题，大概能猜到 op 工作环境。

无脑雪花主键啊。。UUID 不建议，太长和分散，不适合索引

@zhaogaz 你牛逼，这都能扯到工作环境

为了防爬虫丢掉自增 ID 有点小题大做了，用户量不大的话完全可以给进出 API 接口的自增 ID 跑个对称加密，防爬+性能兼得。这年头 AES 加解密的开销比 DB lookup 一个字串 ID 小多了。

用字符串作为 ID 的要注意一下数值特别大的情况，接口返回 JSON 格式时要用程序转成字符串，别超过最大安全数。吃过这方面的亏

@b821025551b 主键都是聚簇索引，都排好序的，为啥会影响读性能？