发布于:2020-01-17 09:44:17
单表的情况下数据库自增id并没有什么问题,在一张表分布到多个数据库的情况下,使用表自增将会出现id重复的问题。
解决的办法有两个方向,一个是在应用层做处理,一个是数据库上去做处理。
目前生成主键方法主要有以下几种:
1、采用mysql自增长主键策略
优点:简单,不需要程序特别处理
缺点:这种方法对以后如果项目移植到其它数据库上改动会比较大,oracle、 db2采用Sequence,mysql、sqlServer又采用自增长,通用性不好
2、使用时间戳+随机数
优点:实现简单,与数据库无关,移植性较好
缺点:长度太长,最少也得20位,不仅占空间并且建索引的话性能会比较差点吧
3、每次取主键最大值+1做为新的主键
优点 :主键长度可控,移植性较好
缺点:并发写可能会造成主键冲突,对并发也不太好控制
4、单独建一个存放主键的表
优点:实现简单,移植性较好
缺点:需要考虑并发问题,整个系统主键生成都依赖该表,性能影响可能较大
即要做到移植性好,性能好,又不会出现并发问题,似乎是没有完美的方案了吗?
一、对于MySQL来说,使用自增还是比较划算的,因为索引使用的底层数据结构(B+树)的原因,如果是自增ID的话,那么数据插入时最多就是引起节点的分裂,而如果是使用非自增ID,则有可能会导致节点移动和分裂。
二、如果使用MySQL又使用UUID作为主键的话,那么插入效率必然大幅下降。
1、当然,使用自增也会带来问题,就是日后如果要做水平切分的话,那么有可能会产生冲突的主键。
2、 而且并发插入的量比较大的时候,MySQL 中如果有自增字段的话,MySQL 会维护一个自增锁,InnoDB 表引擎会在内存里保存一个计数器来记录 AUTO_INCREMENT 值。当插入一个新行数据时,就会用一个表锁来锁住这个计数器,直到插入结束。如果是一行一行的插入是没有问题的,但是在高并发情况下,表锁会引起 SQL 阻塞,极大的影响性能,还可能会达到 max_connections 值。
所以也可以选择不使用数据库的自增,而是自己生成全局唯一的递增整数作为主键。
我们可以自己写一套逻辑, 比如加一些前后缀什么的, 优点就是定制化强而且可以限制长度,缺点就是需要能写出完全随机且支持高并发的程序, 那肯定就有用到pool的一些机制, 以及如何down机的持久化问题, 一般人写不出。
一般点儿的比如我就是就直接用java的uuid方法去生成, 优点就是简单,很轻松的就支持了分库分表, 缺点当然就是长度太长, 占空间大, 且无规律(如果你想要规律的话).
主键和订单号是不一样的, 主键是与业务无关, 而订单号是与业务相关的, 所以不可能完全避免不去写这种生成唯一id的程序, 虽然很难, 订单号可以与时间戳相关加一些随机的后缀(uuid随机截取4位)来实现。
最终方案:
根据自己项目实际情况来定!!!没有一套规定的方案适合任何一个系统。
1、项目基础功能部分,例如菜单功能管理、用户管理、权限管理、机构组织管理、参数管理等采用【方案3】,这些功能一般数据量不大,基本没有大的性能问题和并发问题,如果移植的话改动也比较小 。
2、对于某些流水、日志类的表可采用【方案2】时间戳+随机数,自己写一套生成唯一id的程序,可以采用时间戳+uuid截取最后四位来作为唯一id,时间戳做主键此时会更有意义 。
3、对于系统中大部分实际的业务功能采用【方案1】mysql的自增长策略,这样可减少开发工作量,并且性能和并发都有保障,如果项目就算移植的话,业务功能这部分肯定会有些变动,做二次开发,所以就暂不考虑移植性了。
4、对于分库分表的场景,可以采用雪花算法。针对分库分表的场景其他几种解决方案参照:分布式集群下如何做到唯一序列号
分布式集群下如何做到唯一序列号 https://blog.csdn.net/riemann_/article/details/88858608
原文来自:https://blog.csdn.net/riemann_/article/details/94321174
阅读 343+
10