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

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

› MySQL 5.5 Community Server

› MySQL 5.6 Community Server

› Percona Configuration Wizard

› XtraBackup 搭建主从复制

Great Sites on MySQL

› Percona

› MySQL Performance Blog

› Severalnines

推荐管理工具

› Sequel Pro

› phpMyAdmin

推荐书目

› MySQL Cookbook

MySQL 相关项目

› MariaDB

› Drizzle

参考文档

› http://mysql-python.sourceforge.net/MySQLdb.html

这是一个创建于 3064 天前的主题，其中的信息可能已经有所发展或是发生改变。

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

int

Long

表用

表主键

51 条回复 • 2017-05-16 17:53:08 +08:00

wy315700

2016-06-25 19:13:45 +08:00

short_uuid

sudoz

2016-06-25 20:30:22 +08:00 via Android

万一最大了呢？

colatin

2016-06-25 20:58:37 +08:00

按我说，应该用 varchar

ins

2016-06-25 21:03:03 +08:00

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

Livid

MOD

2016-06-25 21:03:17 +08:00

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

iyaozhen

2016-06-25 21:28:36 +08:00 via Android

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

还有 L 大说的兼容第三方

infun

2016-06-25 21:32:25 +08:00

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

hp3325

2016-06-25 21:42:45 +08:00 via Android

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

qgy18

2016-06-25 21:43:42 +08:00 via iPhone

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

chaegumi

2016-06-25 21:45:56 +08:00

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

redtea

2016-06-25 21:48:21 +08:00

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

wdlth

2016-06-25 21:51:44 +08:00

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

Ouyangan

2016-06-25 21:53:04 +08:00

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

moult

2016-06-25 22:01:17 +08:00

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

ayaseangle

2016-06-25 22:02:01 +08:00

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

bobuick

2016-06-25 22:03:46 +08:00

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

liashui

2016-06-25 22:09:19 +08:00

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

moult

2016-06-25 22:15:25 +08:00

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

infun

2016-06-25 22:18:44 +08:00 via Android

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

fising

2016-06-25 22:24:52 +08:00

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

hantsy

2016-06-25 22:26:28 +08:00

内部 UUID ，外部 Base58

Ouyangan

2016-06-25 22:29:42 +08:00

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

gefranks

2016-06-25 22:31:44 +08:00 via iPhone

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

ETiV

2016-06-25 22:46:14 +08:00 via iPhone

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

mornlight

2016-06-25 22:50:00 +08:00

@ETiV Dota2 ，比赛场数爆了

zkd8907

2016-06-25 22:54:05 +08:00

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

mickeyandkaka

2016-06-26 00:29:05 +08:00

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

Lucups

2016-06-26 00:36:30 +08:00

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

PS ：不要过度设计。

sudoz

2016-06-26 00:40:57 +08:00

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

Livid

MOD

2016-06-26 00:54:14 +08:00

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

programgou

2016-06-26 01:14:40 +08:00

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

viator42

2016-06-26 01:37:07 +08:00 via Android

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

BB9z

2016-06-26 01:54:52 +08:00

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

realpg

2016-06-26 02:04:00 +08:00

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

msg7086

2016-06-26 06:44:43 +08:00

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

beginor

2016-06-26 08:09:53 +08:00 via Android

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

zealinux

2016-06-26 10:10:12 +08:00

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

图未来就用 long

hggg

2016-06-26 11:46:27 +08:00 via iPhone

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

quericy

2016-06-26 12:02:02 +08:00

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

tianice

2016-06-26 12:25:07 +08:00

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

fuxkcsdn

2016-06-26 14:07:57 +08:00

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

starqoq

2016-06-26 15:54:47 +08:00

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

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

Cloudee

2016-06-26 16:54:04 +08:00 via iPhone

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

daydaysay

2016-06-26 18:02:13 +08:00

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

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

daydaysay

2016-06-26 18:03:17 +08:00

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

qiukun

2016-06-26 18:57:38 +08:00 via Android

typedef 一下?

doushiyinweini

2016-06-27 09:18:00 +08:00

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

techme

2016-06-27 11:27:39 +08:00

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

2016-06-27 14:43:20 +08:00

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

symbo

2016-06-29 20:02:09 +08:00

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

arist

2017-05-16 17:53:08 +08:00

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