[大话IT]MySQL使用自增ID和UUID的优劣势比较

loothinker

自定义主键生成方法，主键带上城市/机房/机器的标识，带上时间戳或者机器内序列号等相关因素，可以构造出全网不重复的主键ID，俺家的系统就是如此建立滴

benet1006

有书送吗？

zwfha

digdeep126 发表于 2015-08-11 11:35
mysql 使用UUID，基本就是自找麻烦。
mysql是索引组织表，每一个二级索引，都会存储一分主键。UUID比自增I ...

这是最根本的。。
现在的auto_increment锁有了一定的优化。完全可以用自增ID.

性能优先。。

fuzhufang

个人认为最好使用自增ID。 理由是：效率高，绝对没有重复，id 产生源 可控。
1. 用64位。 几乎永远用不完了。
2. 一定不会有重复，而 UUID 还是有重复的概率
3. MySQL服务器小规模集群（5台数据库服务器以内，主-主集群和主-从集群）的情况，能否使用自增ID，如何避免自增ID的主键冲突。
    解决这个问题很重要。 6 楼的同学已经给出可行的方案了。
    我这里还加一个：产生唯一id，用一个专门的库，它作为唯一id的产生源； 里面有N张表，每张表最多 M 条记录。每张表的id 是自增的。假设M=1亿，那么第一张表就可以产生1~1亿 唯一id；第二张表，1亿零~2亿，依此类推；

UUID 的使用场景已经是：你的ID唯一性，ID源，是不可控。 例如android 系统 apk 包的UUID， 全世界这么多开发者发布apk，那么这个唯一id，只能用UUID了。

wangwenan6

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自己去做吧~~

shang2010

我听58一位技术大牛分享的结果就是

玩单机自增，玩互联网uuid

shang2010

虽然你们分析的道理一大堆，但是我们现在技术都是讲究带结论性的判断

_mrhong

LikeLx

正在学习mysql，希望来本学习下。

ning_lianjie

在Innodb引擎下,使用uuid做主键, 绝对是一个坑跌的选择.