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