这是一个创建于 2431 天前的主题，其中的信息可能已经有所发展或是发生改变。
各位大佬，给点意见与方案
 | 1 lxrmido 2019 年 8 月 9 日 via iPhone 你想怎样，uuid ？ |
 | 2 SuperMild 2019 年 8 月 9 日 uuid 不好吗？ |
 | 3 yamedie 2019 年 8 月 9 日 ObjectId 咯, 上 MongoDB |
 | 4 Takamine 2019 年 8 月 9 日 via Android uuid_generator_v4()。 |
 | 5 z1154505909 2019 年 8 月 9 日 想改变.弄一些不能用自增 id 解决的需求, 至于实际使用的时候 自增能不能满足需求?能,那就用, |
 | 6 chinvo 2019 年 8 月 9 日 如果你在 ID 里面记录时间，可以考虑用 ksuid |
 | 7 ShangAliyun 2019 年 8 月 9 日 各有各的好处，在不怕爬虫的场景，自增增加可读性挺好的，我博客文章现在还是自增 id |
| 8 chinvo 2019 年 8 月 9 日 或者 Snowflow ID |
 | 9 keepeye 2019 年 8 月 9 日 用关系型数据库，自增 ID 咋了？我敢说大部分项目自增 id 足够了，你看 v2 不也是吗？有啥必须的理由不能用自增 id 呢？ |
 | 10 ayonel 2019 年 8 月 9 日 自增 id 的好处非常多。uuid 的随机性，会导致主键索引频繁的分裂、合并，影响插入性能。另外，主键使用 id 的话，数据量小，查询起来也比 uuid 稍快点。 |
 | 11 SpiderShrimp 2019 年 8 月 9 日 uuid |
 | 12 WuwuGin 2019 年 8 月 9 日 @keepeye 自增的拓展性较差，分布式用 uuid 是个好办法，虽然说大部分应用远达不到需要分布式的量级，不过养成习惯也是好的。唯一缺点大概就是排序不能用主键了。 |
 | 13 collery 2019 年 8 月 9 日 主键自增 id 无所谓。 就算分库分表也不能更具 id 这种无意义的键来分。 |
 | 15 lihongjie0209 2019 年 8 月 9 日 @airyland #14 这个问题和分布式没什么关系 |
 | 16 airyland 2019 年 8 月 9 日 @lihongjie0209 我不是直接回复这个问题，是回复上面用户。 |
 | 17 flyingghost 2019 年 8 月 9 日  1 其实问题都没有明确。 自增 ID 怎么了？遇到了什么问题？ 分布式？ 安全隐秘？ 全局唯一性？ 全局自增有序？ 都有增强 /替代方案。 如果只是看着不爽，那闭着眼睛用好了。自增 ID 缺点不少，优点也是大把。何必瞧人家土呢？再土能土得过 TCP/IP 和冯诺依曼计算机架构？还不是天天用。 |
 | 18 dk7952638 2019 年 8 月 9 日 uuid 对索引极不友好，小项目自增，大项目分布式用雪花算法 |
 | 19 wensonsmith 2019 年 8 月 9 日 如果只是安全隐秘， 可以参考 laravel 扩展包 hash_id 如果是分布式 /全局唯一 /全局自增有序，Snowflake， 美团的 Leaf , 微信的发码机制可以看看 |
 | 20 jifengg 2019 年 8 月 9 日 同意 @flyingghost 的观点。要不要用自增要看具体的使用场景。 |
 | 21 1109599636 2019 年 8 月 9 日 做个中间件，还是用 id 但是返回经过中间件转换成"杂乱"的字母字符串，解析请求也经过中间件把字母字符串转换成 id |
 | 22 mineqiqi 2019 年 8 月 9 日 什么级别的用户量？还是说你想了解分布式自增 id 解决方案，自行百度谷歌 |
 | 23 Oktfolio 2019 年 8 月 9 日 反正我是能用 自增 ID 的情况下就用 自增 ID，毕竟在 MySQL 上性能更好。分布式用 UUID 不会遇到重复吗？ snowflake 了解一下。 |
 | 24 annielong 2019 年 8 月 9 日 内部用自增，外部用 uuid |
 | 25 xfriday 2019 年 8 月 9 日 为了和别人不一样，强行不用自增主键，这不是沙雕行为么？用什么方案完全取决于需求 |
 | 26 RH 2019 年 8 月 9 日 via iPhone snowflow |
 | 27 inwar 2019 年 8 月 9 日 via Android 同 snowflake,国内有个美团 leaf 做了一些集成和优化可以了解一下,基本到手可用 |
 | 28 reus 2019 年 8 月 9 日 自增 id 有什么问题？爬虫？你难道不做权限验证？ |
 | 29 uxstone 2019 年 8 月 9 日 极其不建议用 UUID |
 | 30 janxin 2019 年 8 月 9 日 via iPad 完全 get 不到需求 |
 | 31 littlewing 2019 年 8 月 9 日 可以用 UUID 啊，随便你用啥，如果用 InnoDB 的话，最好主键是自增 ID，因为自增 ID 对 B+树的插入效率和空间利用率最高，如果是用 LSM-Tree 比如 levelDB 之类的，应该无所谓了，没太了解过 |
 | 32 zjsxwc 2019 年 8 月 9 日 via Android 自增 id 是有好处的， 可以提高查询与处理效率（比如二分法）， 可以作为唯一原子数据在高并发时使用（比如抢购活动时，作为抢中依据）， 可以提高可读性（对于 24 位头尾字符都一样，只有中间一两个字符不同的 uuid，我是无法肉眼直接分辨的） |
 | 33 ikaros 2019 年 8 月 10 日 这个问题我想了好久, UUID 太长太占空间,自增一是反爬问题,二是很容易被人猜到业务量,解决方法的话可以用 short uuid(类似 twitter 的 snowflake,这个其实也比较长,是个比较大的整数,而且需要和数据库交互一次),思考了一下，最后我用的是随机自增,每次生成 ID 加上一个范围内的随机数,要做分布式的话可以预估业务量仿照 snowflake 在前面加上机器编号 |
| 34 janxin 2019 年 8 月 10 日 |
 | 35 hangszhang 2019 年 8 月 10 日 自增 id 对于索引很友好 |
 | 36 explore365 2019 年 8 月 10 日 自增 ID，索引友好。 至于反爬？一点都不是问题，只有脑子的问题。 |
 | 37 sleepm 2019 年 8 月 10 日 via Android id 只是索引，又不展现出来，前台显示的可以是 order_id 知乎有讨论淘宝订单号规则的 我也见证过京东订单号从 5 开头，到 7 开头，再到 10 开头。。 |
 | 38 ziiber 2019 年 8 月 11 日 自增 ID 什么的没什么吧，楼上说什么爬虫遍历的，谁规定一定要把自增 ID 显示出来了？不会显示其他自定义的嘛？ |
 | 39 stanjia 2019 年 8 月 11 日 雪花 is |
Select Language