MySQL数据库架构设计的基本功就是对于表结构的设计 。
如对于字段类型的选择；表的存储设计 ， 压缩还是非压缩 ， 如何选用压缩算法；表的访问设计 ， SQL还是NoSQL 。
这些问题看似非常简单并容易回答 ， 然而绝大部分的答案却是错的 。
某些错的离谱的答案还在网上年复一年的流传着 ， 甚至还成为了所谓的MySQL军规 。
其中 ， 一个最明显的错误就是关于MySQL的主键设计 。
大部分人的回答如此自信：用8字节的 BIGINT 做主键 ， 而不要用INT 。
这样的回答 ， 只站在了数据库这一层 ， 而没有从业务的角度思考主键到底什么？
主键就是一个自增ID么？
站在2021年的时间当下 ， 用自增做主键 ， 架构设计上可能连及格分都拿不到 。
自增ID的问题自增ID做主键 ， 简单易懂 ， 几乎所有数据库都支持自增类型 ， 只是实现上各自有所不同而已 。
自增ID除了简单 ， 其他都是缺点 ， 总体来看存在以下几方面的问题 。
首先 ， 可靠性不高 。存在自增ID回溯的问题 ， 这个问题直到最新版本的MySQL 8.0才修复 。
其次 ， 安全性不高 。对外暴露的接口可以非常容易猜测对应的信息 。
比如/User/1/这样的接口 ， 可以非常容易猜测用户ID的值为多少 ， 总用户数量有多少 ， 也可以非常容易地通过接口进行数据的爬取 。
另外容易被忽视的一点是 ， 自增ID的性能较差 ， 需要在数据库服务器端生成 。
而且业务还需要额外执行一次类似last_insert_id()的函数才能知道刚才插入的自增值 ， 这需要多一次的网络交互 。
在海量并发的系统中 ， 多1条SQL ， 就多一次性能上的开销 。
最后也是最重要的一点是 ， 自增ID是局部唯一 ， 只在当前数据库实例中唯一 ， 而不是全局唯一 ， 在任意服务器间都是唯一的 。
对于目前分布式系统来说 ， 这简直就是噩梦 。
淘宝的主键设计在淘宝的电商业务中 ， 订单服务是一个核心业务 。
那么请问 ， 订单表的主键淘宝是如何设计的呢？是自增ID么？
打开淘宝 ， 看一下订单信息：
文章插图
从上图可以发现 ， 订单号不是自增ID！！！
接着 ， 我们详细看下上述4个订单号：
1550672064762308113注意到了什么没？订单号是20位的长度 ， 且订单的最后6位都是一样的 ， 都是308113 。
1481195847180308113
1431156171142308113
1431146631521308113
此外 ， 订单号的前面14位部分是单调递增的 。所以 ， 我大胆猜测 ， 淘宝的订单ID设计应该是：
推荐阅读
- 吃什么对肾病有好处,吃什么对男人的性功能有好处
- 女人长期喝白茶有什么好处,喝白茶有什么好处
- 青金桔汁,金桔柠檬茶的做法
- 辛夷花鼻炎偏方,辛夷花的作用
- 糖尿病人能吃枸杞,糖尿病人能吃枸杞吗
- 护肾养肾的养生茶,补肾养肾护肾的区别
- 高速免费的几个节假日有哪些？
- 一身漏洞狂奔24年！WiFi协议被曝重大漏洞，随时成为监控你的工具
- 最简单的白条钓法是什么？
- linux权限管理
