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

[cjbi]

如题，请说明理由，表关联也是用字符串吗？

[LeegoYih]

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

[superedlimited]

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

[vitoliu]

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

[xuanbg]

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

[Chad0000]

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

[Chad0000]

@chendy
@cjbi
@op351

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

[acvrock]

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

[pkoukk]

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

[chendy]

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

[allinoneok]

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

[melkor]

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

[RICKEYGONG]

Guid userId = new Guid();

[leeraya]

bigint 够够的

[b821025551b]

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

[youisme]

@b821025551b 雪花算法是有序的

[afstyle]

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

[Ashore]

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

[cnbattle]

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

[karloku]

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

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

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