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