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支持。 聚簇索引的结构大致如下： 
