使用自增 ID 的内部结构为顺序填充，最大化页面填充率，减少页分裂和碎片，提升性能。然而，自增 ID 也存在潜在问题，如业务增长信息泄露、高并发负载下的锁争用以及自增锁的性能损失。结论是，尽管自增 ID 存在缺点，但在实际开发中，建议遵循 MySQL 官方推荐使用自动增长的主键 ID。MySQL 内部机制...
mysql数据库使用32位的uuid作为主键与使用int自增作为主键
在 MySQL 中设计表时，官方推荐使用自动增长的主键 ID 而非 UUID 或雪花 ID。本文将探讨为何不建议使用 UUID，并分析使用 UUID 的数据库性能问题。
本篇博客将使用控制变量法，通过建立多张表（user_auto_key、user_uuid、user_random_key）并测试它们的插入速度和查询速度。表的区别仅在于主键生成策略，而其它字段保持一致。我们将使用 Spring 的 jdbcTemplate 进行增查测试。
通过技术框架（Springboot+jdbcTemplate+junit+hutool），在相同环境中写入同等数量的数据，分析插入效率。程序采用随机生成的数据，包括名字、邮箱、地址等。
程序写入结果将展示 user_key_auto、user_random_key 和 user_uuid 表的插入情况。同时，通过测试插入 10W 数据，对比在数据量 100W 左右时，UUID 插入效率垫底的现象。
使用 UUID 的索引内部结构与自增 ID 的差异在于，UUID 每次插入的位置不固定，这导致写入目标页可能不在内存中或需要频繁进行页分裂，增加额外操作和数据移动，降低效率。
使用自增 ID 的内部结构为顺序填充，最大化页面填充率，减少页分裂和碎片，提升性能。然而，自增 ID 也存在潜在问题，如业务增长信息泄露、高并发负载下的锁争用以及自增锁的性能损失。
结论是，尽管自增 ID 存在缺点，但在实际开发中，建议遵循 MySQL 官方推荐使用自动增长的主键 ID。MySQL 内部机制复杂，优化空间大，后续开发需深入了解。
本篇博客提供了实验代码和结果分析，以供参考。更多相关技术内容和实践代码请参考附录链接。关注 Java 编程宇宙，获取更多 Java 学习资源。2024-09-09
