mysql uuid 自增_mysql 自增id和UUID作主键性能分析，及最优方案

mysql 自增id和UUID作主键性能分析，及最优方案

1.为何会想到用uuid作主键

(1).其实在innodb存储引擎下，自增加的id作主键性能已经达到了最佳。不管是存储和读取速度都是最快的，并且占的存储空间也是最小。mysql

(2).可是在咱们实际到项目中会碰到问题，历史数据表的主键id会与数据表的id重复，两张自增id作主键的表合并时，id必定会有冲突，但若是各自的id还关联了其余表，这就很很差操做。web

(3).若是使用UUID，生成的ID不只是表独立的，并且是库独立的。对之后的数据操做颇有好处，能够说一劳永逸。sql

2.UUID优缺点

缺点： 1. 影响插入速度， 而且形成硬盘使用率低

2. uuid之间比较大小相对于自增id比较大小要慢不少， 影响查询速度。

3. uuid占空间大， 若是你建的索引越多， 影响越严重数据库

优势：出现数据拆分、合并存储的时候，能达到全局的惟一性svg

3.最优方案

(1).InnoDB引擎表是基于B+树的索引组织表。函数

(2).B+树：B+树是为磁盘或其余直接存取辅助设备而设计的一种平衡查找树，在B+树中，全部记录节点都是按键值的大小顺序存放在同一层的叶节点中，各叶节点指针进行链接。性能

(3).InnoDB主索引：叶节点包含了完整的数据记录。这种索引叫作汇集索引。InnoDB 的索引能提供一种很是快速的主键查找性能。不过，它的辅助索引也会包含主键列，因此，若是主键定义的比较大，其余索引也将很大。若是想在表上定义 、不少索引，则争取尽可能把主键定义得小一些。InnoDB 不会压缩索引ui

(4).汇集索引这种实现方式使得按主键的搜索十分高效，可是辅助索引搜索须要检索两遍索引：首先检索辅助索引得到主键，而后用主键到主索引中检索得到记录。.net

综合上述可得：设计

(1).若是InnoDB表的数据写入顺序能和B+树索引的叶子节点顺序一致的话，这时候存取效率是最高的。为了存储和查询性能应该使用自增加id作主键。

(2).对于InnoDB的主索引，数据会按照主键进行排序，因为UUID的无序性，InnoDB会产生巨大的IO压力，此时不适合使用UUID作物理主键，能够把它做为逻辑主键，物理主键依然使用自增ID。为了全局的惟一性，应该用uuid作索引关联其余表或作外键。

4.若是非要使用uuid作主键，下面是小建议：

若是是主从即M-S模式，最好是不使用mysql自带函数uuid来生成惟一主键，由于主表生成的uuid要再关联从表时，须要再去数据库查出这个uuid，须要多进行一次数据库交互，并且在这个时间差里面主表颇有可能还有数据生成，这样就很容易致使关联的uuid出错。若是真要使用uuid，能够在Java中生成后，直接存储到DB里，这时主从的uuid就是同样的了！