这是一个创建于 517 天前的主题，其中的信息可能已经有所发展或是发生改变。
大家是一般怎么考虑的？直接梭哈雪花算法，为以后的分库分表做无缝切换。
还是等业务量起来要用到分库分表了，才开始用雪花算法
还有大家业务表一般都必然会有什么字段？
比如 create_by update_by create_time update_time 这些？
ps 还是说用到分布式的唯一 id 中间件 比如 tinyid ？
还是等业务量起来要用到分库分表了，才开始用雪花算法
还有大家业务表一般都必然会有什么字段？
比如 create_by update_by create_time update_time 这些？
ps 还是说用到分布式的唯一 id 中间件 比如 tinyid ？
 |
1
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 昨天我微信刚被推了这么个文，我还以为你是转这个来的 |
 |
2
IDAEngine 2023-06-16 10:09:02 +08:00
自增就行了，业务量不大没必要
|
 |
4
burymme11 2023-06-16 10:25:58 +08:00  3
个人建议，
这份业务数据在 1 年内会出产生大量数据，大概率需要做分库分表的话，直接一开始就上分布式 ID 。 如果不是，就自增 ID 先用着，等到时候了再分库分表改造，还能算自己的项目优化提升，加点 KPI ，绩效。 千万别一步到位，更别想一步到位，给自己，给后面的人，都留口饭吃。 |
 |
6
angeloce 2023-06-16 10:35:42 +08:00
从业务最佳实践来讲， 建议用自增作为表主键，另外增加一个 uniqkey 作为业务主键。主要是除了从 MySQL 本身机制外，更需要应用层在 CUD 多种场景里的幂等防重的考虑。
|
 |
7
28Sv0ngQfIE7Yloe 2023-06-16 11:09:05 +08:00
一百万内的数据，自增都没啥毛病，预期几何级别增长的数据量，需要准备分布式 ID
UUID 就是依托答辩，任何情况我都不用 |
|
8
28Sv0ngQfIE7Yloe 2023-06-16 11:09:51 +08:00
另外，一般我习惯用 created_at ,感觉看起来比较顺眼
|
 |
10
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 |
|
11
28Sv0ngQfIE7Yloe 2023-06-16 14:36:15 +08:00
|
 |
12
NXzCH8fP20468ML5 2023-06-16 14:36:54 +08:00 via Android
可以考虑 uuid_short
mysql8 才支持 |
|
14
NXzCH8fP20468ML5 2023-06-16 14:39:27 +08:00 via Android
@iblessyou 你这篇文章里只证明 uuid 不行，没证明雪花不行啊
|
Select Language