如果我们选择 B+ 树作为索引的数据结构，当写入数据时它有如下两个特点：

1，B+ 树索引对于顺序数据插入的维护代价是非常小的。像常见的自增 ID 和时间的插入都是比较快的。

2，B+ 树索引对于无序数据的插入就需要花费较大的索引维护开销，会涉及对页进行分裂、旋转等操作。对于硬盘来讲，随机写的性能也不及顺序写。两者的影响叠加起来就会造成较大的开销。

从上述两点来看，确实是使用自增 ID 值，不使用 UUID 作为主键是较好的。那为什么还要说这是误区呢？

首先，自增 ID 有其自身不足：

1，自增 ID 只能再当前的 MySQL 实例内保证唯一，在分布式架构中无法保证全局唯一。

2，自增 ID 存在比别人猜中数据量（例如：商品量）的情况，有数据安全隐患。

3，高并发的插入时可能出现性能瓶颈。

其次，在 MySQL 8.0 中推出了 UUID_TO_BIN 函数，它提供了如下功能：

1，将 UUID 字符串仲时间高位放在最前面，可以解决插入 UUID 时的乱序问题。

2，去掉无用的“-”字符，并且可以将字符串转换为二进制进行保存，精简存储空间。

通过 UUID_TO_BIN 函数让使用 UUID 作为主键也能收获顺序插入收益。

因此，并不是说使用自增 ID 就一定比使用 UUID 好。需要我们针对实际业务场景进行综合考虑。