V2EX = way to explore
V2EX 是一个关于分享和探索的地方
Sign Up Now
For Existing Member Sign In
› 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
MySQL 相关项目
› MariaDB
› Drizzle
参考文档
› http://mysql-python.sourceforge.net/MySQLdb.html
This topic created in 3605 days ago, the information mentioned may be changed or developed.
int 型已经很大了，有 20 多亿，像用户表用 int 就足够了，用 long 不是浪费吗？
 |
1
wy315700 Jun 25, 2016
short_uuid
|
 |
2
sudoz Jun 25, 2016 via Android
万一最大了呢？
|
 |
3
colatin Jun 25, 2016
按我说，应该用 varchar
|
 |
4
ins Jun 25, 2016
他们是想很长远之后的 需求和省事所以都选 long 型
|
 |
5
Livid MOD PRO  8
如果应用支持第三方登录，或者只使用第三方登录，那么第三方的 User ID 有可能是 64 位的。虽然自己的应用不一定能增长到超过 32 位，但是第三方很可能是 64 位的。
|
 |
6
iyaozhen Jun 25, 2016 via Android
还是有一定道理的，确实能超过 21 亿，改代码都快改哭了。
还有 L 大说的兼容第三方 |
 |
7
GlobalNPC Jun 25, 2016
我司 32 位升级 64 位专门立了个项目
|
 |
8
hp3325 Jun 25, 2016 via Android
浪费？那是你没遇到溢出！
改代码，导数据的时候就不会觉得浪费了。 |
 |
9
qgy18 Jun 25, 2016 via iPhone
百度 passport 当年就遇到 id 长度不够的问题，改了好久。
|
 |
10
chaegumi Jun 25, 2016
int 还要是无符号的，不然对接百度登录就不够
|
 |
11
redtea Jun 25, 2016
突然想到前公司一业务表的从表主键 id 就是 int ，如果业务繁荣的话，估计就要溢出了。
|
 |
12
wdlth Jun 25, 2016
不用自增而用算法生成主键的话，无符号 bigint 也不算多长。
|
 |
13
Ouyangan Jun 25, 2016 1
业务中使用 uuid , 第三方可以另建一张表维护
|
 |
14
moult Jun 25, 2016
听我的，用 char ，存 36 进制的，初期长度不够的时候前面补 0 。。。。。
|
 |
15
ayaseangle Jun 25, 2016
垃圾数据很快就超过了。。
|
 |
16
bobuick Jun 25, 2016
uuid 会影响 index ，各位说用 uuid 的记得指明场景， 不然误导人家了要
|
 |
17
liashui Jun 25, 2016
前期 int ，后期修改为 long 的工作量多大呢？
|
|
18
moult Jun 25, 2016
@liashui 强类型语言的话，伤筋动骨很厉害，一个地方该类型，关联一堆的地方。
PHP 的话，直接查出来是 string 格式的，而且 ID 这种东西一般不会拿来加减乘除，无痛不痒。 |
 |
21
hantsy Jun 25, 2016
内部 UUID ， 外部 Base58
|
 |
23
gefranks Jun 25, 2016 via iPhone
我司一个产品也是快溢出了 出补丁出的疯掉
|
 |
24
ETiV Jun 25, 2016 via iPhone
LoL 还是 DotA （印象中是拳头），之前停机维护，就是因为数据库主键类型选的不够多…
|
 |
26
zkd8907 Jun 25, 2016
腾讯旗下的 QQ 和微信都曾经因为 32 位的问题而专门立项，全公司大改。这个成本不管对于多大的公司来说，都是非常巨大的。
|
 |
27
valuedlute Jun 26, 2016
生成全局唯一的 id ，这样不同业务用同一个 id 生成器后，各个子业务方便合并。
|
 |
28
Lucups Jun 26, 2016
当你有那么大量级的用户笑都来不及，还怕改？
PS ：不要过度设计。 |
 |
31
programgou Jun 26, 2016
|
 |
32
viator42 Jun 26, 2016 via Android
Android 的列表 id 值必须定义为 long
公司后台把只有两种值的字段都定义成了布尔类型，简直是不要命 |
 |
33
BB9z Jun 26, 2016
用户 ID 一般是够了，但用户产生的数据可能要多两个甚至三个数量级，业务发展好的两三年可能就需要考虑了。
|
 |
34
realpg PRO 说明这个公司用的不是 PHP ……
|
 |
35
msg7086 Jun 26, 2016
如果你的系统不打算长期用、大规模用的话，当然可以用 int 。
人家公司是打算做大做强的，当然就用 long 了咯。 你看看现在的 IPv4 不就是 int 么， IP 分配都搞成什么鸟样了…… |
 |
36
beginor Jun 26, 2016 via Android
id 用时间字符串，精确到毫秒后面的三位数，类似这样 201606260812123654 便于排序和查看
|
 |
37
zealinux Jun 26, 2016
图省事就用 int ，
（以后有你哭的，不要说要改的时候，你跑了哦。） 图未来就用 long |
 |
38
hggg Jun 26, 2016 via iPhone
没遇到过 int 不够(T⌓T)，哭晕在厕所
|
 |
39
quericy Jun 26, 2016
我们就是用的 int ，感觉到不了要用 long 的时候。。。。
三方登录单独建表维护 |
 |
40
tianice Jun 26, 2016
很多业务表都会有 userId ，如果后期再改，修改量巨大。
很多公司为了业绩好看，会自己做一些数据，你懂得。。。 |
 |
41
fuxkcsdn Jun 26, 2016
PHP 果然是世界上最好的语言
这算啥事啊，你改下数据库表结构就得啦，关我代码鸟事 |
 |
42
starqoq Jun 26, 2016
我记得 Dota2 的服务器曾经就为对战记录的主键溢出问题下线修补过一次。
官方公告还说 “我们 2038 年会再见面的”。 |
 |
43
Cloudee Jun 26, 2016 via iPhone
反过来想，为啥每条记录多 4 个字节算浪费...等业务量大到需要计较每条记录 4 字节的空间，也要笑开花了吧
|
 |
44
daydaysay Jun 26, 2016
50 亿行记录，用 long ，也就 4 * 21 亿字节 ， 8G 硬盘。 内存不知道，多 8G ？
其实既然有人提出出了用 long ， 我觉得也不麻烦，是好事。 |
|
45
daydaysay Jun 26, 2016
是多用 4 ＊ 21 亿字节。 前一条说得不完整
|
 |
46
qiukun Jun 26, 2016 via Android
typedef 一下?
|
 |
47
doushiyinweini Jun 27, 2016
随便，对于拥有几十亿用户的公司对于改个数据类型都是小儿科。
|
 |
48
techme Jun 27, 2016
嗯，数据库有一些“浪费”是必要的，之前设计一个任务报告的表最多限制能写 2000 字，结果有人写了 8000 多字，页面保存不上去把我们骂的那个惨啊
|
 |
49
JQ Jun 27, 2016
长度不够的情况，遇到过 2 次。
|
 |
50
symbo Jun 29, 2016
@doushiyinweini 成本挺高的。修改，测试，上线，耗费的时间和人力不少。
|
 |
51
arist May 16, 2017
前前任使用了一个诡异的算法在自增主键上生成 id, 前任后来把这段代码废弃，使用默认的自增 id, 不到一周，现任发现游戏新用户注册不了， 检查后发现了 int 溢出， 持续了几个小时，留下一大波差评，惨痛的教训。
|
Select Language