萌新请教,大佬轻喷⁄(⁄ ⁄•⁄ω⁄•⁄ ⁄)⁄
1
qq976739120 2018-10-19 11:19:37 +08:00
单击就用自增吧,分布式有并发的话可以用雪花算法生成主键,也是现成的
|
2
lihongjie0209 2018-10-19 11:32:58 +08:00
uuid debug 的时候你就难受了
|
3
opengps 2018-10-19 11:41:49 +08:00 via Android
先随口说 2 点,~
自增 id 容易被猜解,爬虫,跨权限泄露数据比较容易 uuid 太长,并且有索引碎片,索引多占用空间的问题 |
4
robot777 2018-10-19 11:42:52 +08:00
那生产环境分布式数据库用什么方式好呢,自建一个生成自增 id 的分配服务吗
|
5
rogwan 2018-10-19 11:47:55 +08:00 via Android
一般应用自增足够,那点数据,规律还用猜吗?大数据 分布式按需使用,uuid 都有四五种。
|
6
zjp 2018-10-19 11:53:57 +08:00 via Android
MySQL 的主键不是递增 /减会有性能损失
单机下用雪花算法也不错,递增 & 没有明显规律 |
7
lastpass 2018-10-19 11:59:56 +08:00 via Android
自增 ID 方便排序,获取上 /下节点。而且一般自增 ID 都足够短。
|
9
qichengzx 2018-10-19 12:07:05 +08:00 1
顺势安利一波:Go 实现的高性能全局唯一序列号生成服务 https://github.com/qichengzx/seqsvr
思路来自:干货 | 分布式架构系统生成全局唯一序列号的一个思路 https://mp.weixin.qq.com/s/F7WTNeC3OUr76sZARtqRjw 求 star。 |
12
acr0ss 2018-10-19 12:53:45 +08:00
自增方便有序;
uuid 高并发插入快 |
13
simonliu2018 2018-10-19 12:58:08 +08:00
自增主键(任何有序的序列)插入的时候索引块是连续的,一块写满再创建一块,这样效率显然是很高的。
如果用无序字段作为主键,索引块要经常分裂、合并(设想一堆无序的数字做插入排序),效率自然就差了。 |
14
simonliu2018 2018-10-19 12:59:00 +08:00
@acr0ss uuid 高并发插入快?原理是?
|
15
xuanbg 2018-10-19 13:08:56 +08:00
自增什么都好,就是有两点不好:
1、分表分库会有 ID 冲突,不分表分库就没有这个问题 2、外键是啥在主键入库前你不知道,需要插入后查询回来再赋值,这个有点别扭 |
17
nisekoi 2018-10-19 14:21:28 +08:00
自增 id 不单止容易被遍历,还容易暴露你的业务量,另外一点就是以后你数据量大了需要分库分表的时候会有问题
|
18
wps353 2018-10-19 14:32:09 +08:00
1、Innodb 是 B-Tree 结构存储,自增主键能很好的利用连续硬盘空间,uuid 很有可能导致随机 IO 影响效率。
2、Innodb 中的索引的叶子节点是包含主键的,一般 uuid 都比自增逐渐大,在索引占用空间上自增主键占优势。 |
20
lihongjie0209 2018-10-19 14:53:45 +08:00
@wps353 会快一点, 因为 mysql 内部需要维护一个计数器, 并发访问一定会上锁保护的, 所以获取自增 id 会阻塞
|
21
wps353 2018-10-19 15:01:52 +08:00
@lihongjie0209
这个 autoinc_lock 可以通过 innodb_autoinc_lock_mode=2 参数 设置来避免,当然这样会导致自增不连续。 但是 uuid 导致的随机 IO 更有可能是并发效率降低。 |
22
realpg 2018-10-19 15:02:34 +08:00 1
|
23
iPhonePKAndroid 2018-10-19 16:05:47 +08:00
隐藏业务数量
|
24
derrickT 2018-10-19 17:10:49 +08:00
自增通常来说应该作为 API 中的参数暴露,容易被遍历获取数据,但是性能好,索引效率高
UUID 没有什么规律,字符串,索引效率差,但是不会被遍历 |
25
aborigine 2018-10-19 17:48:51 +08:00
如果是 mysql,自增 id 做主键而且不要用到业务中吧!可以用 uuid 当作 user_id 之类的区分并设成 unique key。原因么,详见高性能 MySQL
|
26
zhzer 2018-10-19 20:32:46 +08:00
分布式无法自增或者说无法同步,就这点区别,干的事都一样
|
27
Moorj 2018-10-19 20:37:41 +08:00
我用 UUID
|
28
abcbuzhiming 2018-10-20 09:16:33 +08:00
@acr0ss uuid 想和自增 id 比插入快你是不是搞错了什么,uuid 保证的是分布式环境下的唯一性,轮性能别和自增 id 比
|
29
abcbuzhiming 2018-10-20 09:18:29 +08:00
@realpg 数字 id 暴露给用户也没啥,关键是要有完善的权限控制系统,数字 id 暴露了就出安全问题明显是设计缺陷
|
30
realpg 2018-10-20 10:57:13 +08:00
@abcbuzhiming #29
并不是,主要是对于自增系统,数字 ID 基本暴露订单量,增量,逻辑关系,对于有心人来说,这非常敏感 |
31
abcbuzhiming 2018-10-20 11:39:34 +08:00
@realpg 我很有兴趣,你说说看有心人就算知道了我的订单量和增量,它能干什么,这就好比公司营业额,你知道了又能做啥
|
32
realpg 2018-10-20 11:50:45 +08:00
@abcbuzhiming #31
我随便举点例子,实际上在有心人那里,能做的东西不止这些 比如你是一个正在吹牛逼拉 C 轮投资的电商,处处造势,日订单量千万,会员三亿,然后被媒体公开,你家 UID 才到九百多万,昨天下单订单号跟今天订单号就差六十多万,完事你家得用多钱去公关这些恶劣影响 商业企业,自身的数据是最值钱的商业机密之一,通过外部参数判断出你家的很多数据,是重要的数据泄露 你要说这些都没啥用,那再来个有实际应用的 公务员报名考试 120 元,很多人愿意花无数个 120 元,就为了摸报名人数 |
33
abcbuzhiming 2018-10-20 15:08:37 +08:00
@realpg 666666,果然多听听别人的脑洞对自己有帮助。我认同你的说法
|
34
013231 2018-10-20 17:06:04 +08:00
|
35
acr0ss 2018-10-20 17:31:27 +08:00
|
36
huadi 2018-10-20 18:08:04 +08:00
@realpg 所以自增不能是纯自增。比如每天或者每 2 小时,增加 10000。当然这样有溢出风险,比如 2 小时内新增用户不能超过 10000
|
38
buliugu 2018-10-21 10:54:47 +08:00
自增的话可以用 Hashids 处理一下
|