有接入过 OAuth 的人应该都发现了， Google ID、Discord ID、Telegram ID 都是大整数，而且都和注册顺序没有直接关系（TGID 和注册顺序有一定关系，但不绝对）这些数据比大小没有意义，为什么不用字符串来存储？

[drymonfidelia]

大整数的兼容性更糟糕，像 TG ID 曾经就出现过因为超过了 int32 的最大值，大量 bot 、第三方客户端工作异常的事件。

[longbowape]

看看雪花算法吧，现在主流的 id 生成都是 int64 了，哪还有抱着 int32 不放的

[Azure99]

您找的是不是：snowflake

[zxkxhnqwe123]

有没有可能是为了查询更快呢，字符串的话还得在转一下吧

[wysnxzm]

@nothingistrue #19 "除了 Mysql 这个用 Java 当底层的"这句话我没看懂

[montaro2017]

@nothingistrue #19 MySQL 用 Java 当底层？？

[jedihy]

超过 32 位就叫大整数，就得用字符串存了？你当 int64 不存在？

[kenvix]

我觉得用字符串才是真魔怔 UUID 也是魔怔

[Terryx]

字符串信息密度可太低了。问题是 int 和字符串有什么本质区别吗？ id 这种东西是自定义数据数类型，唯一需要注意的是字节长度约定。字符串是不存在的，你用字符串去装任意长度的 int 也是可以的啊。

[vituralfuture]

因为比较的时候两个整数可以用一条机器指令，字符串只能逐字符比较，select 的时候快多了

[vituralfuture]

另外因为 id 超过 int32 最大值而无法工作这个问题，首先开发的时候就应该去查文档确定 id 的范围，telegram 应该是在服务端设计之初就确定了 id 的范围和类型

[tool2dx]

为什么老是要和 int32 较劲，现代 C++支持一下 int64 和 int128 ，轻轻松松的好吧。

[flyqie]

你猜猜字符串和大整数哪个方便做索引和底层比较算法

[catamaran]

@kenvix 前公司的技术总监明确要求我们数据库主键用 uuid ，禁止使用 int ，搞得我们手忙脚乱。

[Rehtt]

我记得 qq 号也是整数，甚至可以转成 16 进制登录

[kenvix]

@catamaran #33 合理怀疑这技术总监和数据库厂商有利益输送关系

[kenvix]

@tool2dx #31 Int128 那其实就是 UUID 了，但是很难想象是什么业务会有这么大的需求
(不考虑把 UUID 按字符串存储的睿智操作...)

[iminto]

和注册顺序有关啊，虽然不是递增的，但是有序啊

[drymonfidelia]

@iminto 无序 我有一周内注册的两个 tg ，后注册的那个 id 反而更小

[nevermoreluo]

1. 数据量层面存储 long long 都比 string 小太多，其实单凭这一点感觉存储上就没有存 string 的必要
2. id 解析后是否顺序相关，和 id 展示出来大小可以不相关，id 直接用自增 int 的坏处是，业务模式容易被探知，例如单日新增用户等信息。当然长 id 也有坏处，例如 id 对用户不友好，需要专门的复制粘贴展示页等等
3. 业务量大的时候，负载要分摊到很多机器上，新建一个数据时，分布式生成 id 尤为重要，分布式生成需要离散，足够快速并且全局唯一，全局唯一这个条件导致 id 就不会太短。
4. C++该被吐槽，但是。。。C++存储大整数，没感觉有啥不友好的

[nothingistrue]

@catamaran #29
@kenvix #31
上了高层面，数据设计上就要区分事务性数据和分析性数据了。用于常用业务的事务性数据，数据量往往十万都到不了，这时候离散的 UUID 就是首选。偶尔数据量上去的事务性数据，比如 twitter 这种体量的用户，也是换用雪花 ID 来同时保持离散跟顺序，不搞顺序而不离散的数字。分析性数据，用 UUID 就不合适。