本文主要是介绍mysql为什么不建议使用订单号或者其他形式的业务单号作为主键？，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
mysql为什么不建议使用订单号或者其他形式的业务单号作为主键？
目前我们电商平台的订单号，或者其他业务单号，为了保证唯一，多数都选择的是雪花算法snowflake或者其他变种来生成的。
生成分布式电商业务唯一id的实现，可以参考：https://tech.meituan.com/2017/04/21/mt-leaf.html 美团点评的这篇博客，这篇博客基本涵盖了目前所有的方式方法。
但是，既然保证了分布式全局唯一，那么我们为什么不建议使用订单号或者其他形式的业务单号来作为我们mysql数据库的主键呢？
其实要从以下几个方面来考虑：
一，大部分分布式全局唯一id生成服务产生的id是没有办法保证连续性的（举个简单的例子，雪花算法的一些实现里，中间位置是机器号，上一秒在机器id为3的机器上生成了一个03+时间戳的id，下一秒在机器id为2的机器上生成了一个02+时间戳的id，那么反而下一秒的这个id要先于上一秒的），如果使用不连续的id来作为主键，主键也是索引，而innodb的索引采用的是b+tree，所以每次在插入的时候，都会因为不是有序的，都要去执行一次重排序，引起没必要的计算和内存开销
二，普通索引上存储的是主键的值，即便是保证了我们生成服务的id是有序的，但是我们生成的id都是那种很长的字符串，这样在普通索引上就会存储大量的数据，导致会占用大量的物理空间。
题外话，如果mysql，使用innodb引擎，在不显示声明主键的情况下，mysql会自动选择一列能够唯一标识数据的字段来作为主键，如果不存在这种列，mysql会生成一个隐含字段来作为主键，这个字段是一个长度为6个字节的长整型。
这篇关于mysql为什么不建议使用订单号或者其他形式的业务单号作为主键？的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
