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

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

关于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提高,免费分享,共同学习,一起进步。

Elkan的小破站
请先登录后发表评论
  • latest comments
  • 总共0条评论