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

发布于 1周前 作者 yibo5220 来自 Go语言

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

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

Harmonyos Next教程
40 回复

你想怎样，uuid ？

更多关于Golang Go语言中至今还在用自增 ID 查数据,我想改变,你有好方案吗的实战系列教程也可以访问 https://www.itying.com/category-94-b0.html


uuid 不好吗？

ObjectId 咯, 上 MongoDB

uuid_generator_v4()。

想改变.弄一些不能用自增 id 解决的需求,
至于实际使用的时候
自增能不能满足需求?能,那就用,

如果你在 ID 里面记录时间，可以考虑用 ksuid

各有各的好处，在不怕爬虫的场景，自增增加可读性挺好的，我博客文章现在还是自增 id

或者 Snowflow ID

用关系型数据库，自增 ID 咋了？我敢说大部分项目自增 id 足够了，你看 v2 不也是吗？有啥必须的理由不能用自增 id 呢？

自增 id 的好处非常多。uuid 的随机性，会导致主键索引频繁的分裂、合并，影响插入性能。另外，主键使用 id 的话，数据量小，查询起来也比 uuid 稍快点。

uuid

自增的拓展性较差，分布式用 uuid 是个好办法，虽然说大部分应用远达不到需要分布式的量级，不过养成习惯也是好的。唯一缺点大概就是排序不能用主键了。

主键自增 id 无所谓。 就算分库分表也不能更具 id 这种无意义的键来分。

分布式可能比较麻烦，自增 id 导致数据极其容易被全量遍历抓取，商业数据应该避免。

#14 这个问题和分布式没什么关系

我不是直接回复这个问题，是回复上面用户。

其实问题都没有明确。
自增 ID 怎么了？遇到了什么问题？
分布式？
安全隐秘？
全局唯一性？
全局自增有序？
都有增强 /替代方案。

如果只是看着不爽，那闭着眼睛用好了。自增 ID 缺点不少，优点也是大把。何必瞧人家土呢？再土能土得过 TCP/IP 和冯诺依曼计算机架构？还不是天天用。

uuid 对索引极不友好，小项目自增，大项目分布式用雪花算法

如果只是安全隐秘， 可以参考 laravel 扩展包 hash_id

如果是分布式 /全局唯一 /全局自增有序，Snowflake， 美团的 Leaf , 微信的发码机制可以看看

同意 的观点。要不要用自增要看具体的使用场景。

做个中间件，还是用 id 但是返回经过中间件转换成"杂乱"的字母字符串，解析请求也经过中间件把字母字符串转换成 id

什么级别的用户量？还是说你想了解分布式自增 id 解决方案，自行百度谷歌

反正我是能用 自增 ID 的情况下就用 自增 ID，毕竟在 MySQL 上性能更好。分布式用 UUID 不会遇到重复吗？ snowflake 了解一下。

内部用自增，外部用 uuid

为了和别人不一样，强行不用自增主键，这不是沙雕行为么？用什么方案完全取决于需求

snowflow

同 snowflake,国内有个美团 leaf 做了一些集成和优化可以了解一下,基本到手可用

自增 id 有什么问题？爬虫？你难道不做权限验证？

极其不建议用 UUID

完全 get 不到需求

可以用 UUID 啊，随便你用啥，如果用 InnoDB 的话，最好主键是自增 ID，因为自增 ID 对 B+树的插入效率和空间利用率最高，如果是用 LSM-Tree 比如 levelDB 之类的，应该无所谓了，没太了解过

自增 id 是有好处的，
可以提高查询与处理效率（比如二分法），
可以作为唯一原子数据在高并发时使用（比如抢购活动时，作为抢中依据），
可以提高可读性（对于 24 位头尾字符都一样，只有中间一两个字符不同的 uuid，我是无法肉眼直接分辨的）

这个问题我想了好久, UUID 太长太占空间,自增一是反爬问题,二是很容易被人猜到业务量,解决方法的话可以用 short uuid(类似 twitter 的 snowflake,这个其实也比较长,是个比较大的整数,而且需要和数据库交互一次),思考了一下，最后我用的是随机自增,每次生成 ID 加上一个范围内的随机数,要做分布式的话可以预估业务量仿照 snowflake 在前面加上机器编号

这种需求推荐了解一下类似 Youtube 和 bit.ly 的 hashids，有多种语言的实现。

hashids.org/

自增 id 对于索引很友好

自增 ID，索引友好。
至于反爬？一点都不是问题，只有脑子的问题。

id 只是索引，又不展现出来，前台显示的可以是 order_id
知乎有讨论淘宝订单号规则的
我也见证过京东订单号从 5 开头，到 7 开头，再到 10 开头。。

自增 ID 什么的没什么吧，楼上说什么爬虫遍历的，谁规定一定要把自增 ID 显示出来了？不会显示其他自定义的嘛？

雪花 is

在Go语言中，如果你希望改进使用自增ID查找数据的方式，可以考虑以下几种更为现代和高效的方法：

  1. UUID（Universally Unique Identifier）：使用UUID作为主键，它能在分布式系统中生成全局唯一的标识符。Go语言中有多个库可以生成UUID，如github.com/google/uuid。UUID的好处是无需担心ID冲突，但可能会增加索引和存储的复杂度。

  2. 雪花算法（Snowflake）：Twitter的雪花算法是一种分布式ID生成算法，能够生成全局唯一、有序的ID。Go社区中有开源的雪花算法实现，如github.com/bwmarrin/snowflake。它生成的ID既具有唯一性，又能保持一定的顺序性，便于排序和分页。

  3. 数据库自增ID的变体：如果仍然希望使用类似自增ID的方式，但希望更灵活，可以考虑在数据库层使用序列（Sequence）或自增表的变体。这种方式可以在一定程度上解决自增ID在分布式环境中的局限性。

  4. 哈希索引：如果数据查找主要依赖于非ID字段，可以考虑使用哈希索引或其他高级索引技术，以优化查找性能。

综上所述，选择哪种方案取决于你的具体需求，如数据量、并发量、分布式环境等。UUID和雪花算法是较为通用的解决方案，但在实施前，建议评估其对存储和索引的影响。

回到顶部