uuid 作为主键会存在的问题

[ruandao]

我在看 高性能 mysql

然后，里面提到用 uuid 作为主键会出现插入的性能问题，那么是指 uuid4 吗？

我查看了下 uuid1 好像是时间增序的， 所以应该不会有插入时不是顺序，导致频繁页分裂的问题吧？

我目前的认知是，uuid1 作为主键的话，因为要进索引，会导致性能问题（因为 uuid1 比较长，每个页能容纳的 key 变少了）

有什么缺漏，或者不对的地方吗？

谢谢

[ruandao]

主要是书中一句话：

例如，从性能的角度考虑，使用 UUID 来作为聚簇索引则会很糟糕：它使得聚簇索引的插入变得完全随机，这是最坏的情况，使得数据没有任何聚集特性

[love]

比普通的四字节整数大 4 倍，所以只用在必要的情况下

[binux]

都 0202 年了，PostgreSQL 它不香吗？

[hbolive]

@binux PostgreSQL 香归香，但用什么数据库，往往不是看书的人决定的。。

[ic2y]

1. 如果你用的 innodb 引擎，最好用自增值做主键（主键是聚簇索引）。因为 Mysql 的 innodb 引擎使用自增连续的值，可以规避 B+树的频繁分裂和调整。

2.对于非主键的索引，都是非聚簇索引，每个非聚簇索引的叶子节点存储的是主键的具体值（可以规避插入更新中 B+树的调整）。也就是说：如果主键用 UUID,那么其他的索引都变相的变大了几倍，会导致磁盘空间的浪费。

[okwork]

打算用 uuid 主键，自然是考虑数据量非常大，后期索引效率比较低。实际情况可以用自增主键，同时加一列索引 uuid，按需使用就可以了

[cmdOptionKana]

现在可以考虑采用 Snowflake

[wx3571]

建立非聚簇索引的时候空间要求更大，特别是需要建很多非聚簇索引的时候。索引空间要求变大会造成索引效率变低

[binux]

@hbolive #4 那让决定用什么数据库的人决定用什么做主键去吧。

[hbolive]

@binux 那好，你下午去财务结算下工资，明天不用来了。。

[guokeke]

按照我的理解, 如果你按照 char 类型存储的话还是存在上面的问题，你可以尝试按照 binary 类型存 uuid。
我不一定对，但是 binary 类型是可以优化 uuid 的。

[Foredoomed]

查询性能可能没什么大区别，但是 uuid 索引占的内存会多很多很多

[ruandao]

@Foredoomed 查询性能应该是有影响的，因为 key 占的空间大，然后一个页能存放的 key 就少，然后就多了几次 IO 操作

我这边主要的矛盾是书上讲的是 uuid4 吗，因为 uuid1 的序列是有序的