关于数据库主键生成策略的一些想法
程序员文章站
2022-07-14 17:14:28
...
最近自己在做一个javaWeb项目,使用的SpringMVC+ibatis,基于性能考虑及个人习惯没有使用hibernate。目前数据库用的mysql,对于主键生成采用那一种方法很是头疼,目前生成主键方法主要有以下几种:
1、采用mysql自增长主键策略
:简单,不需要程序特别处理
:这种方法对以后如果项目移植到其它数据库上改动会比较大,oracle、 db2采用Sequence,mysql、sqlServer又采用自增长,通用性不好
2、使用时间戳+随机数
:实现简单,与数据库无关,移植性较好
:长度太长,最少也得20位,不仅占空间并且建索引的话性能会比较差点吧
3、每次取主键最大值+1做为新的主键
:主键长度可控,移植性较好
:并发写可能会造成主键冲突,对并发也不太好控制
4、单独建一个存放主键的表
:实现简单,移植性较好
:需要考虑并发问题,整个系统主键生成都依赖该表,性能影响可能较大
大概就是这几种比较容易想到,
即想做到移植性好,性能好,又不会出现并发问题,似乎是没有完美的方案了吗,不知道有木有童鞋有更好的推荐吗?
既然这样又经过思考后打算根据项目实际情况来定,主要分为以下几种情况
1、项目基础功能部分,例如菜单功能管理、用户管理、权限管理、机构组织管理、参数管理等采用【方案3】,这些功能一般数据量不大,基本没有大的性能问题和并发问题,如果移植的话改动也比较小
2、对于某些流水、日志类的表可采用【方案2】时间戳+随机数,时间戳做主键此时会更有意义
3、对于系统中大部分实际的业务功能采用【方案1】mysql的自增长策略,这样可减少开发工作量,并且性能和并发都有保障,如果项目就算移植的话,业务功能这部分肯定会有些变动,做二次开发,所以就暂不考虑移植性了。
PS:希望童鞋们推荐一些更好的解决方法。
1、采用mysql自增长主键策略
:简单,不需要程序特别处理
:这种方法对以后如果项目移植到其它数据库上改动会比较大,oracle、 db2采用Sequence,mysql、sqlServer又采用自增长,通用性不好
2、使用时间戳+随机数
:实现简单,与数据库无关,移植性较好
:长度太长,最少也得20位,不仅占空间并且建索引的话性能会比较差点吧
3、每次取主键最大值+1做为新的主键
:主键长度可控,移植性较好
:并发写可能会造成主键冲突,对并发也不太好控制
4、单独建一个存放主键的表
:实现简单,移植性较好
:需要考虑并发问题,整个系统主键生成都依赖该表,性能影响可能较大
大概就是这几种比较容易想到,
即想做到移植性好,性能好,又不会出现并发问题,似乎是没有完美的方案了吗,不知道有木有童鞋有更好的推荐吗?
既然这样又经过思考后打算根据项目实际情况来定,主要分为以下几种情况
1、项目基础功能部分,例如菜单功能管理、用户管理、权限管理、机构组织管理、参数管理等采用【方案3】,这些功能一般数据量不大,基本没有大的性能问题和并发问题,如果移植的话改动也比较小
2、对于某些流水、日志类的表可采用【方案2】时间戳+随机数,时间戳做主键此时会更有意义
3、对于系统中大部分实际的业务功能采用【方案1】mysql的自增长策略,这样可减少开发工作量,并且性能和并发都有保障,如果项目就算移植的话,业务功能这部分肯定会有些变动,做二次开发,所以就暂不考虑移植性了。
PS:希望童鞋们推荐一些更好的解决方法。
上一篇: Handler学习小结
下一篇: 深入理解jvm分享培训pdf