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