关于uuid与自增列的选择

关于uuid与自增列的选择

在db交流群里看到有人提问，说他的userName 登录名是唯一的，可以用其做主键嘛，如果用自增列，那又要多一列。

后面又说，如果要用主键ID，用uuid会不会好一些呢？作为新手的我也对这个问题发生了兴趣，百度检索下得出大致结论：

uuid：可以简单的的理解为全球唯一标识符

一、缺点

　　1.无序性：uuid是无序的， 插入数据时，页的位置会发生变化，页分裂，速度慢。一般情况下主键是聚簇索引，会把相邻主键的数据安放在相邻的物理存储上。如果主键不是自增，而是随机的，那么频繁的插入会使 innodb 频繁地移动磁盘块，而影响写入性能。

　　2.占空间大：uuid占的空间大，并且别的索引还都要包含主键的值，那么每个索引的空间也都会增大，占的空间大，需要读数据时一般会认为需要的io次数多, 如果需要分库分表，往往是海量数据，这个时候使用UUID不是一个好的选择（占用空间太大）。主键一般情况下追求短整型，确定好你的整型类型（根据需求）。

二、优点

　　1.数据离散化便于发布集群

　　2.利于水平分割

　　3.数据多写，合并复制等分布式操作

自增ID：可以简单理解成一个自增的序列

缺点：

　　1.不利于水平分割

　　2.插入增加增量，删除不减少增量

　　3.数据聚集化不便于发布集群

　　4.主键冲突。

　　系统大了点，要考虑分布式，甚至数据库双写之类，这样的策略是不够的。举个例子，系统做了双机房，想做一个数据库的异地双向同步。那么当双方还没同步的情况下，可能录入了同样的ID。当然了，只是双机房的话还是可以用 increase by 的方式，把数据库自增步伐修改为奇偶。比如说机房1的主库是基数的ID，机房2的主库是偶数的ID。双向同步创建数据来说就没有冲突了。（双向同步还有好多问题的，并发下的update时序问题等这里不展开讨论）

优点：即uuid缺点的反向

总结：

　　总体需要看你索引适应的形式，如果使用 b-tree 索引形式，有序 id 比无需 id 好，如果是 hash 索引，两个差别不大。
　　主要原因是索引在磁盘上存储的形式，常用的 b-tree 索引如果 id 是连续的，那么数据存储在相邻的磁盘上，如果查询和写入操作的 id 连续，那么减少随机读写硬盘的几率，提升读写效率。
　　所以看你的实际情况，如果你用的是 b-tree 索引，同时记录比较多，那么用有序 id 作为索引效率会高很多。具体情况题主可以自己测试一下，差距明显。

考虑因素要点 ：

　　1.随机IO与顺序IO

　　2.页分裂与所占空间大小

　　3.分库分表以及分布式集群

　　4.对等拓扑、合并复制、数据多写

 

 

 

 

参考自：

1.http://www.cnblogs.com/ELMND/p/4863577.html

2.https://www.zhihu.com/question/43500172