未分類
13 4 月 2020

uuid 作为主键会存在的问题

uuid 作为主键会存在的问题

資深大佬 : ruandao 57

我在看 高性能 mysql

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

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

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

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

谢谢

大佬有話說 (13)

  • 主 資深大佬 : 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 的序列是有序的