Mysql用UUID做主键可行么

Mysql中是否可以使用UUID作为主键？UUID可以用作MySQL中的逻辑主键。
物理主键始终使用自增ID1和UUID定义。
UUID的含义是通用唯一标识符（UniversallyUniqueIdentifier）。
）。
它是构建软件的标准，也被开源软件使用。
它是分布式计算环境（DCE）领域基金会组织应用程序（OpenSoftwareFoundation，OSF）的一部分。
UUID是指在一台机器上生成的一个数字，保证在同一时间和空间内的所有机器上都是唯一的。
2、UUID的优点1）可以保证独立性，程序可以在不同数据库之间迁移而不影响效果。
2）确保生成的ID不仅与表无关，而且与数据库无关。
当您想要拆分数据库时，这一点尤其重要。
3）Oracle进行数据迁移时，不会因为表顺序不连续而出现问题。
3、UUID的缺点1）它比INT类型占用更多的空间，存储一个UUID需要更多的空间。
2）使用UUID后，URL显得很长，不够友好。

为什么MySQL不建议使用自增idmysql不建自增id

为什么MySQL不鼓励使用自动递增ID？MySQL是常用的关系型数据库，开发中经常会涉及到数据表的设计和使用。
一般情况下，我们会在每个表中添加一个自增ID作为主键，以区分每条数据。
但是，MySQL不建议总是使用自增id作为主键。
我们来看看原因。
1.数据表的复制和合并在实际开发中，有时需要合并或复制两个数据表。
如果两个表都有自增ID，就会出现主键冲突，导致数据表无法正常工作。
因此，MySQL建议使用全局唯一标识符（例如UUID或GUID）作为主键，以避免此类冲突。
2、分布式系统在分布式系统中，每个节点都可以有自己的自增ID，因此在合并数据时会出现相同的自增ID，导致数据冲突。
因此，在分布式系统中使用自增ID作为主键并不是一个好的选择。
相反，使用全局唯一标识符作为主键可以避免此问题。
3.容易受到攻击使用自增ID作为主键会暴露大量信息。
攻击者可以利用系统的自增ID来推断表中的数据总量、时间戳等信息。
如果此信息影响您系统的安全，我们不建议使用自动递增ID。
相比之下，使用UUID或GUID作为主键更安全。
我们看一下使用自增ID和使用UUID或GUID作为主键的性能和可读性对比：1.性能使用自增ID显然会更快，因为自增ID只需要查询当前表中最大的ID自增然后加1。
使用UUID或者GUID需要比较耗时的操作才能保证生成的ID是全局唯一的。
因此，如果系统对性能要求很高，就必须做出妥协和选择。
2、可读性使用自增ID作为主键，可读性更好，可以轻松展示表中数据的增长情况。
相比之下，根据UUID或GUID生成的主键可读性较差，难以快速查询表。
综上所述，MySQL并不建议在所有情况下都使用自增ID作为主键。
在设计数据表时，需要根据实际情况进行选择，选择最适合自己系统当前需求的主键方式。
当然，总体来说，全局唯一标识符更加安全、灵活，并且比自动递增的ID更有优势。

用雪花id和uuid作MySQL主键，被领导怼了！

在MySQL中设计表时，官方建议避免使用UUID或非连续、不重复的雪花ID（长、唯一、单机增量），而建议使用连续、自增的ID。
主键ID。
即自动增量。
那么为什么不鼓励使用UUID呢？使用UUID的缺点是什么？在这篇博客中，我们将分析这个问题并探讨原因。
首先，我们需要创建三个表：user_auto_key、user_uuid和user_random_key。
它们分别表示自动递增主键、UUID作为主键和随机键作为主键。
我们按照控制变量的方法，只改变每个表的主键生成策略，其他字段保持不变，来测试表的插入和查询速度。
本程序使用Spring的jdbcTemplate来实现额外的验证测试，技术框架为springboot+jdbcTemplate+junit+hutool。
程序原理是连接自己的测试数据库，在相同环境下写入相同量的数据，分析插入时间，综合评价效率。
所有数据（例如姓名、电子邮件和地址）都是随机生成的。
现有数据量为130W时，插入10W数据的测试结果表明，数据量在100W左右时UUID插入效率最低，然后添加130W数据明显减少了UUID时间。
效率顺序为auto_key>random_key>uuid，其中UUID效率最低。
当数据量很大时，效率会迅速下降。
为什么会出现这种情况呢？接下来我们就来探讨一下这个问题。
自增ID的内部结构是顺序的，InnoDB在记录之后存储每条记录。
当达到页面的最大填充因子时，下一条记录将写入新页面。
这种加载主键页面的顺序方法增加了最大页面填充率并避免了页面浪费。
同时，新插入的行肯定会是原始最大数据行之后的下一行。
MySQL的定位和寻址速度非常快，并且减少了数据生成，因为计算新行的位置没有额外的消耗。
页面分裂和碎片。
使用UUID的索引的内部结构不如顺序自动递增ID规则。
由于新行值不一定大于先前的主键值，因此InnoDB不能总是将新行插入索引的末尾，并且必须找到新的合适位置来分配新行。
新空间。
这个过程需要很多额外的操作，数据杂乱会导致数据分布变得分散，导致以下问题：正在写入的页面可能已刷新到磁盘并从缓存中删除，或者可能尚未写入。
当加载到缓存中时，InnoDB必须从磁盘中找到目标页面并将其读入内存然后再插入，从而导致大量的随机IO。
由于乱序写入，InnoDB必须执行频繁的页分割操作来为新行分配空间，导致大量数据被移动并且插入改变至少3页。
频繁分页会导致页面变得稀疏且填充不规则，最终导致数据碎片。
将随机值（UUID和SnowflakeID）加载到聚集索引（InnoDB的默认索引类型）后，您可能需要运行OPTIMIZETABLE来重建表并优化页面填充。
这需要一些时间。
使用InnoDB时，应尽可能按升序主键顺序插入，并尽可能插入具有单调递增聚集键值的新行。
使用自动递增ID也存在一些问题。
例如，当其他人爬取您的数据库时，可以根据数据库的自增ID检索业务增长信息，让您轻松分析业务状况。
-InnoDB的并发加载、基于主键的插入会导致明显的锁争用，主键上限成为争用热点，因为所有插入都在这里完成，并且并发插入会导致间隙锁争用。
Auto_Increment锁机制引入了自增锁的争用，这在一定程度上降低了性能。
实际开发中，最好遵循MySQL官方推荐，使用自增ID。
因为MySQL如此博大精深，内部有很多值得优化和学习的地方。