至今还在用自增 ID 查数据,我想改变,你有好方案吗

2019-08-09 13:25:30 +08:00
 jss

各位大佬,给点意见与方案

6872 次点击
所在节点    Go 编程语言
39 条回复
lxrmido
2019-08-09 13:53:47 +08:00
你想怎样,uuid ?
SuperMild
2019-08-09 13:57:35 +08:00
uuid 不好吗?
yamedie
2019-08-09 13:58:48 +08:00
ObjectId 咯, 上 MongoDB
Takamine
2019-08-09 13:59:07 +08:00
uuid_generator_v4()。
z1154505909
2019-08-09 14:00:17 +08:00
想改变.弄一些不能用自增 id 解决的需求,
至于实际使用的时候
自增能不能满足需求?能,那就用,
chinvo
2019-08-09 14:00:58 +08:00
如果你在 ID 里面记录时间,可以考虑用 ksuid
ShangAliyun
2019-08-09 14:01:08 +08:00
各有各的好处,在不怕爬虫的场景,自增增加可读性挺好的,我博客文章现在还是自增 id
chinvo
2019-08-09 14:01:23 +08:00
或者 Snowflow ID
keepeye
2019-08-09 14:02:45 +08:00
用关系型数据库,自增 ID 咋了?我敢说大部分项目自增 id 足够了,你看 v2 不也是吗?有啥必须的理由不能用自增 id 呢?
ayonel
2019-08-09 14:10:50 +08:00
自增 id 的好处非常多。uuid 的随机性,会导致主键索引频繁的分裂、合并,影响插入性能。另外,主键使用 id 的话,数据量小,查询起来也比 uuid 稍快点。
SpiderShrimp
2019-08-09 14:11:33 +08:00
uuid
WuwuGin
2019-08-09 14:12:10 +08:00
@keepeye 自增的拓展性较差,分布式用 uuid 是个好办法,虽然说大部分应用远达不到需要分布式的量级,不过养成习惯也是好的。唯一缺点大概就是排序不能用主键了。
collery
2019-08-09 14:14:06 +08:00
主键自增 id 无所谓。 就算分库分表也不能更具 id 这种无意义的键来分。
airyland
2019-08-09 14:17:00 +08:00
@keepeye 分布式可能比较麻烦,自增 id 导致数据极其容易被全量遍历抓取,商业数据应该避免。
lihongjie0209
2019-08-09 14:18:55 +08:00
@airyland #14 这个问题和分布式没什么关系
airyland
2019-08-09 14:27:27 +08:00
@lihongjie0209 我不是直接回复这个问题,是回复上面用户。
flyingghost
2019-08-09 14:34:32 +08:00
其实问题都没有明确。
自增 ID 怎么了?遇到了什么问题?
分布式?
安全隐秘?
全局唯一性?
全局自增有序?
都有增强 /替代方案。

如果只是看着不爽,那闭着眼睛用好了。自增 ID 缺点不少,优点也是大把。何必瞧人家土呢?再土能土得过 TCP/IP 和冯诺依曼计算机架构?还不是天天用。
dk7952638
2019-08-09 14:58:04 +08:00
uuid 对索引极不友好,小项目自增,大项目分布式用雪花算法
wensonsmith
2019-08-09 15:03:41 +08:00
如果只是安全隐秘, 可以参考 laravel 扩展包 hash_id

如果是分布式 /全局唯一 /全局自增有序,Snowflake, 美团的 Leaf , 微信的发码机制可以看看
jifengg
2019-08-09 15:21:38 +08:00
同意 @flyingghost 的观点。要不要用自增要看具体的使用场景。

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/590448

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX