为什么不建议使用自增ID作为参与业务计算处理逻辑的字段？

本文链接：https://blog.csdn.net/SDTechnology/article/details/146236717

自增ID不适合作为业务逻辑字段，这背后其实是一个技术设计和业务需求之间的错位问题。自增ID是数据库为了方便记录管理而设计的工具，但它并不适配业务的复杂性和灵活性。我们可以从几个关键点来拆解这个问题。

自增ID没有业务意义，业务逻辑需要“看得懂”的东西

自增ID本质上是一个技术工具，它的唯一性是为了让数据库内部管理记录更高效。但业务逻辑需要的是能承载语义的标识，比如订单号、用户ID这些字段，它们不仅要唯一，还得能传递信息。举个例子，像物料编号“RAW001”，前缀“RAW”直接告诉你这是原材料，后面三位是序列号，这种设计在记录、传播、甚至口头交流中都很方便。而自增ID只是一个数字，完全没有这种语义化的能力。

更重要的是，业务逻辑往往需要字段具备一定的可读性和规则性。比如订单号可能需要包含时间戳、地区码等信息，而自增ID的单调递增特性完全无法满足这些需求。直接把自增ID用在业务逻辑里，等于是让业务去迁就技术，而不是让技术服务于业务。

自增ID的不连续性会打破业务逻辑的预期

虽然自增ID在数据库里不连续并不影响功能，但在某些业务场景下，这种不连续性可能是个大问题。比如订单编号、会员卡号这些字段，业务上可能默认它们是连续的。如果因为事务回滚、插入失败等原因导致ID跳跃，前端展示或者数据分析时就会出现混乱。

更麻烦的是，这种不连续性会让系统显得不够专业。想象一下，用户看到订单号从1001直接跳到1003，可能会怀疑系统是不是出了问题。这种信任危机虽然看似小事，但在用户体验至上的今天，可能直接影响业务。

高并发场景下，自增ID会成为性能瓶颈

在高并发的系统里，自增ID的生成机制会拖累性能。因为每次插入操作都需要访问同一个计数器，这会导致锁竞争，尤其是在MySQL这种单线程的存储引擎下。锁竞争不仅会降低插入效率，还可能引发事务阻塞，影响整个系统的稳定性。

另外，自增ID的连续性也让它容易成为攻击目标。恶意用户可以通过观察ID的递增规律，推测出系统的数据规模和生成规则，进而发起针对性的攻击。这种安全隐患在金融、电商等对安全性要求极高的领域尤其致命。

分布式系统里，自增ID根本玩不转

随着业务规模扩大，系统往往会走向分布式架构，而自增ID在这种环境下完全不适用。因为每个节点生成的自增ID可能会冲突，导致数据引用关系混乱。这也是为什么很多分布式系统会选择雪花ID（Snowflake ID）这样的方案。雪花ID通过时间戳、节点ID等信息生成全局唯一的ID，既避免了冲突，又能保证一定的有序性。

当然，还有UUID这种方案，但它的性能和可读性较差，实际应用中并不如雪花ID受欢迎。分布式系统的复杂性决定了，自增ID这种单机环境下的简单工具已经无法满足需求。