mysql innodb uuid主键_mysql InnoDB UUID 主键 性能优化【原理篇】.md

##1. mysql InnoDB 表主键用uuid还是int类型的自增序列？

主键大多场景还是自增序列类型，效率高

1.自增序列

简单，存储空间效率高

适合简单的管理系统；单库环境

分库处理麻烦一下；需要配置offset，数据整合复杂

2.uuid

一些场景，更适合uuid

分库分表：UUID支持对表进行水平划分，将数据分布存储在多台不同的机器上，动态扩缩容。

内存生成对象，对象id在内存做关联运算时，可以使用uuid或分布式int id；

【如果用序列，需要和db通信后，才能获取id；】

数据经过多个server处理后，才入库；如分布式发现资源、子资源，集中入库；dcs产生数据、ccs入库

3.分布式id

自定义int类型主键生成算法；

用分布式int类型的id，如redis产生id

本文针对uuid使用进行优化

##2.UUID

###2.1UUID概念

UUID(Universally Unique Identifier)全局唯一标识符,是指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的

UUID是16字节128位长的数字，通常以36字节的字符串表示，示例如下：

f5a96171-0045-11e5-9cc7-fcaa1490706f 其中的字母是16进制表示，大小写无关。

uuid36位去掉- 为32位

###2.1UUID排序

标准的UUID格式为：xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (8-4-4-4-12)

UUID组成：

(1)当前日期和时间，UUID的第一个部分与时间有关，如果你在生成一个UUID之后，过几秒又生成一个UUID，则第一个部分不同，其余相同。

(2)时钟序列。

(3)全局唯一的IEEE机器识别号，如果有网卡，从网卡MAC地址获得，没有网卡以其他方式获得。

要想每次生成的uuid有序，就需要把时间放后，机器码提前。

排序示例

原始uuid 22886ea0-0048-11e5-9e24-fcaa1490706f 转换后 11e5-0048-9e24-fcaa1490706f-22886ea0

原始uuid 229c92e1-0048-11e5-9e24-fcaa1490706f 转换后 11e5-0048-9e24-fcaa1490706f-229c92e1

###2.3JAVA 的UUID

Java UUID Generator (JUG)：开源UUID生成器，LGPL协议，支持MAC地址。

java 自带uuid

##3.为什么需要UUID有序

###3.1InnoDB引擎表的一些关键特征

InnoDB引擎表是基于B+树的索引组织表(IOT)；

每个表都需要有一个聚集索引(clustered index)；

所有的行记录都存储在B+树的叶子节点(leaf pages of the tree)；

基于聚集索引的增、删、改、查的效率相对是最高的；

如果我们定义了主键(PRIMARY KEY)，那么InnoDB会选择其作为聚集索引；

如果没有显式定义主键，则InnoDB会选择第一个不包含有NULL值的唯一索引作为主键索引；

如果也没有这样的唯一索引，则InnoDB会选择内置6字节长的ROWID作为隐含的聚集索引(ROWID随着行记录的写入而主键递增，这个ROWID不像ORACLE的ROWID那样可引用，是隐含的)。

综上总结，如果InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的.

自增序列效率高的原因；uuid无序，就要想办法使其相对有序。

###3.2MySQL聚簇索引

MySQL聚簇索引保证关键字的值相近的元组存储的物理位置也相同(所以随机字符串，会使得系统进行大量的移动操作)，且一个表只能有一个聚簇索引。因为由存储引擎实现索引，所以，并不是所有的引擎都支持聚簇索引。目前，只有solidDB和InnoDB支持。

聚簇索引的结构大致如下：