为什么很多公司要求 mysql 表主键 id 必须是 long 型？

short_uuid

万一最大了呢？

按我说，应该用 varchar

他们是想很长远之后的 需求和省事所以都选 long 型

如果应用支持第三方登录，或者只使用第三方登录，那么第三方的 User ID 有可能是 64 位的。虽然自己的应用不一定能增长到超过 32 位，但是第三方很可能是 64 位的。

还是有一定道理的，确实能超过 21 亿，改代码都快改哭了。

还有 L 大说的兼容第三方

我司 32 位升级 64 位专门立了个项目

浪费？那是你没遇到溢出！
改代码，导数据的时候就不会觉得浪费了。

百度 passport 当年就遇到 id 长度不够的问题，改了好久。

int 还要是无符号的，不然对接百度登录就不够

突然想到前公司一业务表的从表主键 id 就是 int ，如果业务繁荣的话，估计就要溢出了。

不用自增而用算法生成主键的话，无符号 bigint 也不算多长。

听我的，用 char ，存 36 进制的，初期长度不够的时候前面补 0 。。。。。

垃圾数据很快就超过了。。

uuid 会影响 index ，各位说用 uuid 的记得指明场景， 不然误导人家了要

前期 int ，后期修改为 long 的工作量多大呢？

@liashui 强类型语言的话，伤筋动骨很厉害，一个地方该类型，关联一堆的地方。
PHP 的话，直接查出来是 string 格式的，而且 ID 这种东西一般不会拿来加减乘除，无痛不痒。

@liashui C#工作量还是蛮大的

@Livid 就算有第三方登录，也不应该用第三方的 openId 作为用户表的主键吧？

内部 UUID ， 外部 Base58

@bobuick 有这个道理, 如果说真有性能瓶颈了, 倒说明这产品发展的不错.

我司一个产品也是快溢出了 出补丁出的疯掉

LoL 还是 DotA （印象中是拳头），之前停机维护，就是因为数据库主键类型选的不够多…

@ETiV Dota2 ，比赛场数爆了

腾讯旗下的 QQ 和微信都曾经因为 32 位的问题而专门立项，全公司大改。这个成本不管对于多大的公司来说，都是非常巨大的。

生成全局唯一的 id ，这样不同业务用同一个 id 生成器后，各个子业务方便合并。

当你有那么大量级的用户笑都来不及，还怕改？

PS ：不要过度设计。

@zkd8907 JD 也是，还是商品 sku ，当初没想过会有那么多商品……

@fising 如果有的应用不生成自己的 User ID ，而直接用第三方的 User ID 的话。

[设计一个可扩展的用户登录系统]( http://www.liaoxuefeng.com/article/001437480923144e567335658cc4015b38a595bb006aa51000)

Android 的列表 id 值必须定义为 long
公司后台把只有两种值的字段都定义成了布尔类型，简直是不要命

用户 ID 一般是够了，但用户产生的数据可能要多两个甚至三个数量级，业务发展好的两三年可能就需要考虑了。

说明这个公司用的不是 PHP ……

如果你的系统不打算长期用、大规模用的话，当然可以用 int 。
人家公司是打算做大做强的，当然就用 long 了咯。
你看看现在的 IPv4 不就是 int 么， IP 分配都搞成什么鸟样了……

id 用时间字符串，精确到毫秒后面的三位数，类似这样 201606260812123654 便于排序和查看

图省事就用 int ，
（以后有你哭的，不要说要改的时候，你跑了哦。）

图未来就用 long

没遇到过 int 不够(TT)，哭晕在厕所

我们就是用的 int ，感觉到不了要用 long 的时候。。。。
三方登录单独建表维护

很多业务表都会有 userId ，如果后期再改，修改量巨大。
很多公司为了业绩好看，会自己做一些数据，你懂得。。。

PHP 果然是世界上最好的语言
这算啥事啊，你改下数据库表结构就得啦，关我代码鸟事

我记得 Dota2 的服务器曾经就为对战记录的主键溢出问题下线修补过一次。

官方公告还说 “我们 2038 年会再见面的”。

反过来想，为啥每条记录多 4 个字节算浪费...等业务量大到需要计较每条记录 4 字节的空间，也要笑开花了吧

50 亿行记录，用 long ，也就 4 * 21 亿字节 ， 8G 硬盘。 内存不知道，多 8G ？

其实既然有人提出出了用 long ， 我觉得也不麻烦，是好事。

是多用 4 ＊ 21 亿字节。 前一条说得不完整

typedef 一下?

随便，对于拥有几十亿用户的公司对于改个数据类型都是小儿科。

嗯，数据库有一些“浪费”是必要的，之前设计一个任务报告的表最多限制能写 2000 字，结果有人写了 8000 多字，页面保存不上去把我们骂的那个惨啊

长度不够的情况，遇到过 2 次。

@doushiyinweini 成本挺高的。修改，测试，上线，耗费的时间和人力不少。

前前任使用了一个诡异的算法在自增主键上生成 id, 前任后来把这段代码废弃，使用默认的自增 id, 不到一周，现任发现游戏新用户注册不了， 检查后发现了 int 溢出， 持续了几个小时，留下一大波差评，惨痛的教训。