核心业务别再用自增主键设计了

核心业务别再用自增主键设计了

关于MySQL表设计，为什么核心业务不要使用自增设计？
**一、用自增主键的好处 **
用BIGINT的自增类型作为主键，数据库插入是顺序的，性能较好。 不过仅适合在非核心业务表，比如告警表、日志表等。真正的核心业务表，一定不要用自增键做主键，主要有 6 个原因： 1、自增存在回溯问题；
2、自增值在服务器端产生，存在并发性能问题；
3、自增值做主键，只能在当前实例中保证唯一，不能保证全局唯一；
4、公开数据值，容易引发安全问题
5、MGR（MySQL Group Replication） 可能引起的性能问题；
6、分布式架构设计问题。

注意： 因为回溯问题，核心表还是坚持使用自增主键设计，那MySQL 数据库版本应该尽可能升级到 8.0 版本。

二、核心业务表建议使用UUID主键设计
UUID（Universally Unique Identifier）代表全局唯一标识 ID。显然，由于全局唯一性，你可以把它用来作为数据库的主键。
MySQL 数据库遵循 DRFC 4122 命名空间版本定义的 Version 1规范，可以通过函数 UUID自动生成36字节字符。如：

SELECT UUID();

e0ea12d4-6473-11eb-943c-00155dbaa39d
根据 Version 1的规范，MySQL中的 UUID 由以下几个部分组成：

UUID = 时间低（4字节）- 时间中高+版本（4字节）- 时钟序列 - MAC地址

三、使用uuid作为主键存储占用空间和插入性能问题
1、MySQL 8.0 提供的排序 UUID 性能最好，甚至比自增ID还要好。此外，由于UUID_TO_BIN转换为的结果是16 字节，仅比自增 ID 增加 8 个字节，最后存储占用的空间也仅比自增大了 3G。

2、而且由于 UUID 能保证全局唯一，因此使用 UUID 的收益远远大于自增ID。可能你已经习惯了用自增做主键，但在海量并发的互联网业务场景下，更推荐 UUID 这样的全局唯一值做主键。

3、比如，我特别推荐游戏行业的用户表结构设计，使用 UUID 作为主键，而不是用自增 ID。因为当发生合服操作时，由于 UUID 全局唯一，用户相关数据可直接进行数据的合并，而自增 ID 却需要额外程序整合两个服务器 ID 相同的数据，这个工作是相当巨大且容易出错的。

结尾： 一、6月回归更新了，会继续做学习笔记和分享。 二、最近在学习MySQL优化方面的知识，主要来源于腾讯金融数据平台与研发中心总监：姜承尧。有兴趣的同学可以加群，加群回复：MySQL提高，免费分享，共同学习，一起进步。