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

[jss]

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

[1109599636]

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

[mineqiqi]

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

[Oktfolio]

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

[annielong]

内部用自增，外部用 uuid

[xfriday]

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

[RH]

snowflow

[inwar]

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

[reus]

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

[uxstone]

极其不建议用 UUID

[janxin]

完全 get 不到需求

[littlewing]

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

[zjsxwc]

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

[ikaros]

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

[janxin]

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

hashids.org/

[hangszhang]

自增 id 对于索引很友好

[explore365]

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

[sleepm]

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

[ziiber]

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

[stanjia]

雪花 is