mysql数据库使用32位的uuid作为主键与使用int自增作为主键

在MySQL中设计表时，官方建议使用自增主键ID，而不是UUID或snowID。
本文将讨论为什么不推荐使用UUID，并分析使用UUID的数据库性能结果。
本博客将使用变量控制创建几个表（user_auto_key、user_uuid、user_random_key）并测试它们的插入速度和查询速度。
这些地图仅在策略生成的主键上有所不同，其他领域保持不变。
我们将使用TruejdbcTemplate进行进一步的检查测试。
通过技术框架（Springboot+jdbcTemplate+junit+hutool），在相同环境下分析相同数据量的插入效率。
该程序使用随机生成的数据，包括姓名、电子邮件地址等。
写入该事件的目的将显示插入用户的用户状态、user_random_key和user_uuid记录。
同时，在插入10W数据的实验中，当数据量在100W左右时，UUID插入效率垫底。
用户索引UUID与自增ID内部结构的区别在于，每次插入UUID的站点并不固定，导致脚本页面在内存中不拆分或者位于频繁页面；它增加了额外的操作和移动数据，并降低了效率。
内部采用自增ID结构进行顺序填充，最大化页面填充率，减少页面分裂和破损，提高性能。
但自生ID也存在潜在的问题，比如流量增长数据泄露、高并发负载下争查、自生毛发丢失等。
结论是，管缺乏自增ID，但在实际开发中，还是建议遵循MySQL官方的建议，使用自增主ID。
MySQL内部引擎复杂且占用大量空间。
本博客提供实验代码和分析结果供参考。
更多技术概念和实用代码请参考附录链接。
关注Java编程世界，了解更多Java资源。

「MySQL」-自增主键id

MySQL中主键ID自增的机制和实现细节是数据库设计者和开发者不可忽视的关键要素。
在讨论这个话题之前，我们首先要明确的是，在计算机系统中，虽然自然数的阶数没有明确的上限，但在实际使用场景中，数据存储的大小限制了自增ID的最大值。
在MySQL数据库中，自增主键ID通常是通过“AUTO_INCRMENT”属性来实现的。
以测试库中的表为例，如果'AUTO_INCRMENT'设置为'2^32-1'，即无符号整数类型'UINT'的最大值，则插入数据时会出现主键冲突错误。
这是因为“AUTO_INCRMENT”的值被限制在特定的范围内，一旦达到上限，就无法继续增加，导致后续的插入操作失败。
因此，对于需要频繁插入和删除操作的表，建议使用较大的数据类型，例如“h3intunsigned”，以适应较大的自增ID需求。
设计表结构时，要充分考虑数据量和边界条件，保证自增ID的连续性和可用性。
在InnoDB存储引擎中，当表没有显式指定主键时，系统会自动创建一个长度为6字节的“row_id”作为内部标识符。
该“row_id”值由InnoDB维护的全局变量“dict_sys.row_id”提供，并在每次插入数据时递增。
事实上，`row_id`是一个unsignedlong，但在实现时只使用了6个字节的空间，导致际值范围在`0`到`2^48-1`之间。
当row_id值达到上限时，再次插入相同的值时，实际上会覆盖之前的数据。
这意味着当使用row_id作为内部ID时，需要特别注意其循环复用特性，尤其是当数据库运行时间较长且数据量较大时。
为了避免数据被覆盖，在设计表结构时应该主动创建自增主键，而不是依赖系统分配的row_id。
综上所述，合理设计和使用自增主键ID对于数据库系统的稳定性和高效性至关重要。
在实际开发中，应根据数据量、操作频率、业务需求灵活选择合适的自增强ID实现方式，保证数据库资源的高效利用和数据的一致性。