这是一个创建于 1960 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位大佬，给点意见与方案
 |
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
|
Select Language