为什么mysql不推荐使用uuid或者雪花id作为主键？

为什么mysql不推荐使用uuid或者雪花id作为主键？

UUID和雪花算法在生成时并非递增序列，在未进行分库分表的情况下使用它们作为数据库主键可能导致MySQL的页分裂问题和磁盘的随机读问题。然而，雪花算法在分布式数据库中作为主键是主流实现方案。

我们需要了解分布式ID的原因是，当系统数据量过大并已完成分库分表后，需要对分散在各个库表中的数据记录进行唯一标识，而分布式ID恰能解决这一问题。

接下来，我们探讨八大分布式ID的生成方案及其优缺点。

首先，UUID是一种“通用唯一识别码”，由32个16进制数字与4个“-”组成，长度为36个字符。版本4的UUID通过随机数生成，实现简单，本地生成，性能高，但生成的ID无序，存储成本高，可读性差。

数据库自增ID方案选择一个数据库作为中央数据库，利用该库中某表的自增主键机制生成分布式ID。此方案单调递增，本地生成，可读性高，但涉及数据库操作，性能较低，需要额外引入中央数据库，增加链路复杂度和出错概率，且开发成本相对较高，数据库压力大。

通过Redis的INCR自增命令生成分布式ID，同样单调递增，ID生成性能高，本地生成，可读性高，但同样需要额外引入Redis，增加链路复杂度和出错概率，且Redis宕机后数据恢复较慢，开发成本相对较高。

雪花算法是Twitter公司开源的分布式ID生成算法，技术实现简单，生成的分布式ID趋势递增，本地生成，出错率低，性能高，但强依赖机器时钟，时钟回拨会导致ID重复，可读性差。

数据库号段方案在数据库自增ID的基础上优化，通过从中央数据库获取号段并缓存到本地，业务系统直接递增获取ID，趋势递增，本地生成，性能高，数据库压力小，但开发成本高，需要额外引入分布式ID服务和中央数据库，增加链路复杂度和出错概率。

美团Leaf分布式ID生成方案包括数据库号段模式（Leaf-segment）和雪花算法模式（Leaf-snowflake），其中Leaf-snowflake方案与雪花算法类似，但将SnowFlake服务独立化，并引入Zookeeper解决时钟回拨问题，趋势递增，解决时钟回拨问题，性能高，但第三方开源软件使用需熟悉成本，链路复杂，可读性差。

滴滴Tinyid分布式ID生成算法基于号段模式实现，支持数据库多主节点模式，并提供客户端接入方式，还做了号段预加载优化。趋势递增，性能高，数据库压力小，但第三方开源软件使用需熟悉成本，链路复杂。

百度UidGenerator是基于Snowflake算法的唯一ID生成器，提供自定义workerId位数和初始化策略，单机QPS可达600万，性能极高，但第三方开源软件使用需熟悉成本，强依赖机器时钟，可读性差。

目前最常用的分布式ID生成方案是雪花算法和数据库号段方式，但应根据系统特性进行选择。

分享一套深入浅出、细致易懂的高频面试题详解，旨在提升学习效率，需要者可获取。

强烈建议有求职诉求的Javaer仔细阅读。2024-11-14