数据库主键是直接用雪花算法还是自增主键

2023-06-16 09:42:56 +08:00
 ppllss
大家是一般怎么考虑的?直接梭哈雪花算法,为以后的分库分表做无缝切换。
还是等业务量起来要用到分库分表了,才开始用雪花算法

还有大家业务表一般都必然会有什么字段?
比如 create_by update_by create_time update_time 这些?

ps 还是说用到分布式的唯一 id 中间件 比如 tinyid ?
1483 次点击
所在节点    问与答
14 条回复
iblessyou
2023-06-16 10:08:37 +08:00
使用雪花 id 或 uuid 作为 Mysql 主键,被老板怼了一顿!
https://mp.weixin.qq.com/s?__biz=MzkyMjI2MTkxOQ==&mid=2247486882&idx=1&sn=def61010aaf44428bd4152d55ec09153

昨天我微信刚被推了这么个文,我还以为你是转这个来的
IDAEngine
2023-06-16 10:09:02 +08:00
自增就行了,业务量不大没必要
ppllss
2023-06-16 10:11:47 +08:00
@iblessyou 🤣
burymme11
2023-06-16 10:25:58 +08:00
个人建议,
这份业务数据在 1 年内会出产生大量数据,大概率需要做分库分表的话,直接一开始就上分布式 ID 。
如果不是,就自增 ID 先用着,等到时候了再分库分表改造,还能算自己的项目优化提升,加点 KPI ,绩效。
千万别一步到位,更别想一步到位,给自己,给后面的人,都留口饭吃。
ppllss
2023-06-16 10:28:14 +08:00
@burymme11 👍 有道理
angeloce
2023-06-16 10:35:42 +08:00
从业务最佳实践来讲, 建议用自增作为表主键,另外增加一个 uniqkey 作为业务主键。主要是除了从 MySQL 本身机制外,更需要应用层在 CUD 多种场景里的幂等防重的考虑。
Morii
2023-06-16 11:09:05 +08:00
一百万内的数据,自增都没啥毛病,预期几何级别增长的数据量,需要准备分布式 ID
UUID 就是依托答辩,任何情况我都不用
Morii
2023-06-16 11:09:51 +08:00
另外,一般我习惯用 created_at ,感觉看起来比较顺眼
leo97
2023-06-16 13:30:51 +08:00
@Morii UUID 有啥劣势吗?
GiftedJarvis
2023-06-16 13:45:00 +08:00
推荐 Spring Data 的命名方式: https://github.com/spring-projects/spring-data-commons/tree/main/src/main/java/org/springframework/data/annotation

CreatedBy, CreatedDate, LastModifiedBy, LastModifiedDate
Morii
2023-06-16 14:36:15 +08:00
@leo97

没啥优势啊。小项目的时候自增很方便,大项目 uuid 又会碰撞,没有雪花好。

目前没有遇到使用 uuid 会更好的场景
xxfye
2023-06-16 14:36:54 +08:00
可以考虑 uuid_short
mysql8 才支持
iblessyou
2023-06-16 14:37:54 +08:00
@ppllss 这个文应该可以很好解决你的问题了
xxfye
2023-06-16 14:39:27 +08:00
@iblessyou 你这篇文章里只证明 uuid 不行,没证明雪花不行啊

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

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

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

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

© 2021 V2EX