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

[eightqueen]

int 型已经很大了，有 20 多亿，像用户表用 int 就足够了，用 long 不是浪费吗？

[wy315700]

short_uuid

[sudoz]

万一最大了呢？

[colatin]

按我说，应该用 varchar

[ins]

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

[Livid]

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

[iyaozhen]

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

还有 L 大说的兼容第三方

[infun]

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

[hp3325]

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

[qgy18]

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

[chaegumi]

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

[redtea]

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

[wdlth]

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

[Ouyangan]

业务中使用 uuid , 第三方可以另建一张表维护

[moult]

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

[ayaseangle]

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

[bobuick]

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

[liashui]

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

[moult]

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

[infun]

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

[fising]

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