各位大佬,给点意见与方案
1
lxrmido 2019-08-09 13:53:47 +08:00 via iPhone
你想怎样,uuid ?
|
2
SuperMild 2019-08-09 13:57:35 +08:00
uuid 不好吗?
|
3
yamedie 2019-08-09 13:58:48 +08:00
ObjectId 咯, 上 MongoDB
|
4
Takamine 2019-08-09 13:59:07 +08:00 via Android
uuid_generator_v4()。
|
5
z1154505909 2019-08-09 14:00:17 +08:00
想改变.弄一些不能用自增 id 解决的需求,
至于实际使用的时候 自增能不能满足需求?能,那就用, |
6
chinvo 2019-08-09 14:00:58 +08:00
如果你在 ID 里面记录时间,可以考虑用 ksuid
|
7
ShangAliyun 2019-08-09 14:01:08 +08:00
各有各的好处,在不怕爬虫的场景,自增增加可读性挺好的,我博客文章现在还是自增 id
|
8
chinvo 2019-08-09 14:01:23 +08:00
或者 Snowflow ID
|
9
keepeye 2019-08-09 14:02:45 +08:00
用关系型数据库,自增 ID 咋了?我敢说大部分项目自增 id 足够了,你看 v2 不也是吗?有啥必须的理由不能用自增 id 呢?
|
10
ayonel 2019-08-09 14:10:50 +08:00
自增 id 的好处非常多。uuid 的随机性,会导致主键索引频繁的分裂、合并,影响插入性能。另外,主键使用 id 的话,数据量小,查询起来也比 uuid 稍快点。
|
11
SpiderShrimp 2019-08-09 14:11:33 +08:00
uuid
|
12
WuwuGin 2019-08-09 14:12:10 +08:00
@keepeye 自增的拓展性较差,分布式用 uuid 是个好办法,虽然说大部分应用远达不到需要分布式的量级,不过养成习惯也是好的。唯一缺点大概就是排序不能用主键了。
|
13
collery 2019-08-09 14:14:06 +08:00
主键自增 id 无所谓。 就算分库分表也不能更具 id 这种无意义的键来分。
|
15
lihongjie0209 2019-08-09 14:18:55 +08:00
@airyland #14 这个问题和分布式没什么关系
|
16
airyland 2019-08-09 14:27:27 +08:00
@lihongjie0209 我不是直接回复这个问题,是回复上面用户。
|
17
flyingghost 2019-08-09 14:34:32 +08:00 1
其实问题都没有明确。
自增 ID 怎么了?遇到了什么问题? 分布式? 安全隐秘? 全局唯一性? 全局自增有序? 都有增强 /替代方案。 如果只是看着不爽,那闭着眼睛用好了。自增 ID 缺点不少,优点也是大把。何必瞧人家土呢?再土能土得过 TCP/IP 和冯诺依曼计算机架构?还不是天天用。 |
18
dk7952638 2019-08-09 14:58:04 +08:00
uuid 对索引极不友好,小项目自增,大项目分布式用雪花算法
|
19
wensonsmith 2019-08-09 15:03:41 +08:00
如果只是安全隐秘, 可以参考 laravel 扩展包 hash_id
如果是分布式 /全局唯一 /全局自增有序,Snowflake, 美团的 Leaf , 微信的发码机制可以看看 |
20
jifengg 2019-08-09 15:21:38 +08:00
同意 @flyingghost 的观点。要不要用自增要看具体的使用场景。
|
21
1109599636 2019-08-09 15:34:38 +08:00
做个中间件,还是用 id 但是返回经过中间件转换成"杂乱"的字母字符串,解析请求也经过中间件把字母字符串转换成 id
|
22
mineqiqi 2019-08-09 16:36:48 +08:00
什么级别的用户量?还是说你想了解分布式自增 id 解决方案,自行百度谷歌
|
23
Oktfolio 2019-08-09 16:43:45 +08:00
反正我是能用 自增 ID 的情况下就用 自增 ID,毕竟在 MySQL 上性能更好。分布式用 UUID 不会遇到重复吗? snowflake 了解一下。
|
24
annielong 2019-08-09 17:09:15 +08:00
内部用自增,外部用 uuid
|
25
xfriday 2019-08-09 19:47:55 +08:00
为了和别人不一样,强行不用自增主键,这不是沙雕行为么?用什么方案完全取决于需求
|
26
RH 2019-08-09 19:48:45 +08:00 via iPhone
snowflow
|
27
inwar 2019-08-09 20:04:22 +08:00 via Android
同 snowflake,国内有个美团 leaf 做了一些集成和优化可以了解一下,基本到手可用
|
28
reus 2019-08-09 20:43:57 +08:00
自增 id 有什么问题?爬虫?你难道不做权限验证?
|
29
uxstone 2019-08-09 20:53:24 +08:00
极其不建议用 UUID
|
30
janxin 2019-08-09 23:32:53 +08:00 via iPad
完全 get 不到需求
|
31
littlewing 2019-08-09 23:42:06 +08:00
可以用 UUID 啊,随便你用啥,如果用 InnoDB 的话,最好主键是自增 ID,因为自增 ID 对 B+树的插入效率和空间利用率最高,如果是用 LSM-Tree 比如 levelDB 之类的,应该无所谓了,没太了解过
|
32
zjsxwc 2019-08-09 23:50:00 +08:00 via Android
自增 id 是有好处的,
可以提高查询与处理效率(比如二分法), 可以作为唯一原子数据在高并发时使用(比如抢购活动时,作为抢中依据), 可以提高可读性(对于 24 位头尾字符都一样,只有中间一两个字符不同的 uuid,我是无法肉眼直接分辨的) |
33
ikaros 2019-08-10 09:08:43 +08:00
这个问题我想了好久, UUID 太长太占空间,自增一是反爬问题,二是很容易被人猜到业务量,解决方法的话可以用 short uuid(类似 twitter 的 snowflake,这个其实也比较长,是个比较大的整数,而且需要和数据库交互一次),思考了一下,最后我用的是随机自增,每次生成 ID 加上一个范围内的随机数,要做分布式的话可以预估业务量仿照 snowflake 在前面加上机器编号
|
34
janxin 2019-08-10 09:42:47 +08:00
|
35
hangszhang 2019-08-10 14:35:57 +08:00
自增 id 对于索引很友好
|
36
explore365 2019-08-10 18:26:56 +08:00
自增 ID,索引友好。
至于反爬?一点都不是问题,只有脑子的问题。 |
37
sleepm 2019-08-10 20:23:10 +08:00 via Android
id 只是索引,又不展现出来,前台显示的可以是 order_id
知乎有讨论淘宝订单号规则的 我也见证过京东订单号从 5 开头,到 7 开头,再到 10 开头。。 |
38
ziiber 2019-08-11 01:07:30 +08:00
自增 ID 什么的没什么吧,楼上说什么爬虫遍历的,谁规定一定要把自增 ID 显示出来了?不会显示其他自定义的嘛?
|
39
stanjia 2019-08-11 19:42:39 +08:00
雪花 is
|