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

mysql InnoDB uuid 主键 性能优化【原理篇】.md mysql InnoDB UUID 主键 性能优化【实践篇】.md 有序uuid mysql InnoDB UUID 主键 性能优化【原理篇】.md 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支持。 　　聚簇索引的结构大体以下：