- 论坛徽章:
- 0
|
本帖最后由 wangwenan6 于 2015-08-21 11:11 编辑
1、MySQL单数据库服务器的情况,使用自增ID和UUID各自的优缺点。
UUID需要一套特殊的机制去生成,从而保证每一个UUID的唯一性,这个“特殊的机制”,根据所对应的数据量来看的话,纯算法类的机制估计自己设计的没几个有这种能力的,而使用现成的算法的话,生成这种UUID的时间开销不可预计,这种不可预计的东西应该尽量避免;
从业务上去设计UUID的话,说白了,还是要有一个类似于“自增的机制”来区分具体某个业务下面的不同数据,相比较于自增列,多此一举
PS:如果能有一套合理的机制来利用UUID简化查询的话,应该还是不错的,这是能玩出花样的地方,做到了就是如同神一般~233333
自增列简单粗暴明了,+1就是了
单库,绝大多数情况下自增列比UUID会好
2、MySQL服务器小规模集群(5台数据库服务器以内,主-主集群和主-从集群)的情况,能否使用自增ID,如何避免自增ID的主键冲突。
MySQL的replication本身就会在主-主集群之间用increment来避免自增列的重复,这是由MySQL本身的机制保证的,正常不会出问题,(以下为个人看法)充其量,在写操作不均匀的情况下,会出现1,2,3,5,7,9,11....这种情况,偶数行少了很多......
主-从结构的话,自增列想不到出现重复的情况,除了有人上从库去手动添加了数据,然而这种情况,不该数据库背锅
3、MySQL单数据库服务器、MySQL服务器小规模集群的情况下,使用自增ID和UUID各自的性能情况。、
没用过UUID,无法评价,不过在1主1从的结构下做过其他方面sysbench的测试,感觉自增列应该是没什么影响,感觉不出来
4、MySQL中大规模集群,如何能够更好地使用UUID,是否有更好的方法。
中大规模集群的话,用GTID吧,这个功能在5.6的GA版应该是比较稳定了,同步的维护也很方便,唯一性也能 保障;
UUID真没用过,只是感觉,在原本的系统上加上这个UUID的功能,会多出很多麻烦的事情,
不仅多了一个生成UUID的模块,还要有一套机制保证UUID的生成不会拖慢系统性能,保证这个UUID的模块在各种情况下不会崩溃or出现其他问题,如果出问题了还要有一套机制/流程去保证系统的正常运行,etc......
想想就脑袋疼,所以还是扔给DB自己去做吧~~ |
|