本文探讨了MySQL Innodb存储结构中，顺序主键与随机主键（如雪花算法、UUID、自增ID）对效率的影响。分析表明，顺序主键在插入和查询时更优，尤其是在B+树索引下。UUID和自增ID在性能上有不同表现，UUID占用空间大，查询排序速度慢；自增ID虽节省空间，但在大量数据时可能导致主键页填充问题。大型项目中，UUID因跨库合并的便利性更受青睐。
说到id之前，先说一下mysql数据库的Innodb的主键索引，因为这和索引息息相关。
我们知道，在Innodb中，采用的是B+数索引。Innodb的存储结构，是聚簇索引。对于聚簇索引，
(1)顺序主键和随机主键的对效率的影响很大。我们分插入和查询来讲：
插入。在磁盘中，有一个页的概念，而一页的容量是固定的，每一页按顺序存储数据，一般数据量达到一页的15/16，则开始存到下一页。但如果主键是随机的，那么每次插入之前，为了找到它的位置，首先需要进行一次比较，找到它的合适位置，再进行插入。如果是在页尾，那自然是最理想的效果。
UUID和自增长在程序中怎么实现此处不讲，我们直接从性能和实际使用来分析。
说到性能，就不等不提到索引，此处以InnoDB的BTree索引来讲。
uuid类型是varchar(36)，而自增长Id则一般是bigInt类型。
首先，大家要知道，id作为唯一索引，并不总是能提高效率。对于非常小的表，大部分情况下简单的全表扫描效率更高，对于中大型的表，索引才非常有效。因为索引帮助存储快速查找到记录的同时，也会带来额外的消耗。
那么索引会带来哪些额外的消耗呢？空间和时间。
下面做了一个实验，在一个有足够内存容纳索引的服务器上插入100万条记录和300百万条记录，时间和空间上的消耗如下：
最低0.47元/天 解锁文章
扫一扫
637
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
