数据量大时，UUID效率为何低于其他主键？

我们来举个例子。假设有一张用户表格。创建以UUID为主键的表。将一百万行数据插入。创建一个表，主键设为随机不重复的ID。插入一百万行数据，随机ID且不重复。UUID为128位字符串，与整型主键相比，其占用更多存储空间。当数据量在100万左右时，uuid的插入效率最差，后续再增加130万数据，uuid的效率又大幅下降。从总体的时间占用量能打出的效率排名来看：auto_key>random_key>uuid，uuid的效率是最低的，数据量较大时，其效率会直线下降。内部结构中使用自增id的情况。

使用Innodb时，应尽量按主键自增顺序插入，插入新行时尽可能采用单调递增的聚簇键的值。于是，我归纳出了一段话。UUID生成与索引更新开销大，随机不重复ID的生成和索引更新开销则较小。