MySQL主键的选取


MySQL索引的数据结构

Mysql是由B+树构成。

为什么要用B+树:

数据库系统的设计者巧妙利用了磁盘预读原理,将一个节点的大小设为等于一个页,这样每个节点只需要一次I/O就可以完全载入。为了达到这个目的,在实际实现B+Tree还需要使用如下技巧:每次新建节点时,直接申请一个页的空间,这样就保证一个节点物理上也存储在一个页里,加之计算机存储分配都是按页对齐的,就实现了一个node只需一次I/O。

B+Tree的节点都是按照键值的大小顺序存放的,叶节点之间也通过指针连接起来,为了提高取数据时的效率。

主键的选取

自增id

Mysql会按照键值的大小进行顺序存放,如果我们设置自增id为主键,这个时候主键是按照一种紧凑的顺序写入的方式进行存储数据。

如果我们用其他字段作为主键的话,此时Mysql不得不为了将新记录插到合适位置而移动数据,甚至目标页面可能已经被回写到磁盘上而从缓存中清掉,此时又要从磁盘上读回来,这增加了很多额外的开销,同时频繁的移动、分页操作造成了大量的碎片。

uuid或者自增id+步长

小规模分布式在数据量不大,使用成本最低的方式就直接用uuid,或者自增id+步长的方式,省时省力。

自建的id生成器

当数据量比较大,又是分布式架构的时候,可能我们需要考虑各种分库分表方案了,这个时候就不能贪图方便,必须有更好更长远的方案来替代。自建id生成器,可以保证全局唯一,可以参考snowflake的算法方案,具体实施也可以根据自身业务进行调整算法。唯一麻烦的就是id生成器的高可用问题,需要多加注意。

Snowflake算法

分布式id生成算法的有很多种,Twitter的SnowFlake就是其中经典的一种。

SnowFlake算法生成id的结果是一个64bit大小的整数,它的结构如下图:

由于在Java中64bit的整数是long类型,所以在Java中SnowFlake算法生成的id就是long来存储的。

SnowFlake可以保证:

利用SnowFlake算法可以有什么扩展呢?

  1. 根据自己业务修改每个位段存储的信息。算法是通用的,可以根据自己需求适当调整每段的大小以及存储的信息。
  2. 解密id,由于id的每段都保存了特定的信息,所以拿到一个id,应该可以尝试反推出原始的每个段的信息。反推出的信息可以帮助我们分析。比如作为订单,可以知道该订单的生成日期,负责处理的数据中心等等。

参考博文

  1. https://segmentfault.com/a/1190000009530839
  2. https://segmentfault.com/a/1190000011282426 想详细了解Snowflake算法的运算过程可参考此文章