查看原文
其他

MySQL 8.0.30版本发布,这个功能我等了10年!

破产码农 InsideMySQL 2022-10-13
点击卡片,关注 InsideMySQL

MySQL 8.0.30版本发布,这个版本没有带来类似Hash Join、Instant Add Column、Clone Plugin这样核弹级的功能,但却带来了一个姜老师期盼10年之久的功能,GIPK:Generated Invisible Primary Key,隐式主键功能。

对于MySQL熟悉的小伙伴都知道,InnoDB存储引擎是索引组织表,每张表都有一个ROWID列,数据根据ROWID排序存放。ROWID的选择如下:

1. 若定义了主键,则主键列就是ROWID列;

2. 若没有主键列,则第一个被定义为NOT NULL的唯一索引列即为ROWID列;

3. 其他场景,则InnoDB存储引擎会自动创建一个6字节的隐式主键列;

然而,第3种创建ROWID的场景会导致一个非常严重的问题!

不好意思,手抖了下,问题不是她们。

这个严重的问题是在进行主从同步的时候,由于没有了主键,从机的回放效率极差,大概率会引起主从的延迟,继而影响业务的读取,容灾切换的时效性等各种问题。

主从复制延迟的主要原因是虽然InnoDB存储引擎层可以感知自己创建的ROWID主键列,但是MySQL Server层却无法感知。因为MySQL数据库的表结构中并没有这个列。从机的回放是在Server上层实现,无法感知InnoDB层的隐藏列。

此外,隐式主键也很容易导致在默认的RR事务隔离级别下产生全局的行级锁,表现形式就类似全表被锁住了。这样数据库的整体吞吐率亦会受到很大的影响。

虽然每个MySQL数据库规范都会写到建表要主动创建一个主键,但在真正的实现生产过程中会遇到一些阻力或问题。因为对于大厂来说,有一套完善的流程管控,而大部分公司没有这样规范的管控机制,导致他们在使用MySQL数据库遇到各种各样的问题。

因此,从产品设计角度看,这是谁的问题?MySQL的错?InnoDB的错?

以上全错。

MySQL没有错,InnoDB也没有错,但是MySQL + InnoDB就错了。

要解决这个问题,本质是MySQL在InnoDB层面会自动创建的隐式主键(若没有显示指定创建ROWID列),并且这个隐藏主键不仅对InnoDB引擎层可见,对MySQL Server层也要可见。

这样,即便用户没有遵循规范,MySQL也会自动创建一个主键,这样可以方便解决没有主键导致复制同步、加锁等各种问题。

我们知道腾讯云、阿里云等都有自动创建隐藏主键的功能,并且该主键是在MySQL Server层创建的,以此解决公有云上用户使用MySQL数据库不规范,从而导致的各种问题。

MySQL 8.0.30版本的GIPK功能实现更为优雅,结合列的Invisible特性,推出了隐式创建自增主键的功能。

换句话说,只要将参数sql_generate_invisible_primary_key设置为ON,若用户没有显式创建主键,MySQL自身会创建隐藏的列my_row_id,并将其定义为主键,该列的定义如下所示:

my_row_id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT INVISIBLE PRIMARY KEY

不得不说,官方GIPK的设计真的很优雅,不但解决了InnoDB引擎创建隐式主键的问题,甚至是解决了所有存储引擎表的问题。而且满足如果用户希望读取ROWID列的话,可以通过隐藏列my_row_id或_rowid标识来访问。如:

对于GIPK这个特性来说,唯一需要注意的是:主从服务器间的配置要严格一致。确保参数sql_generate_invisible_primary_key在主从的值是一样的。因为,若从机没有设置GIPK为ON,这就意味着复制不会为从机上的表生成隐藏的主键列。

GIPK特性真的太棒,解决了很多新手使用MySQL数据库的问题。但是到这就结束了么?不一定。

换位思考,若我是MySQL数据库的首席产品经理,我会如何持续打磨这个功能呢?

首先,我会将参数sql_generate_invisible_primary_key的默认值设置为ON(当前为OFF),这看起来没有太大的坏处。

当然,如果是低版本到高版本的数据同步,从机会多1个隐藏的列,但感觉这并不会导致太大的问题。

另一方面,用BIGINT做自增主键虽然可以,但不是最优解的主键推荐,因此可以提供设置隐藏主键的类型,如BIGINT,UUID等。这样就可以新增参数:sql_generate_invisible_primary_key_type

到这,做内核研发的小伙伴们是不是跃跃欲试了呢?

BTW,你们的生产系统是否已经升级到了MySQL 8.0版本呢?其中又遇到了哪些坑呢?欢迎留下你的评论。


今日思考题


问题1: 作为产品经理,除了添加sql_generate_invisible_primary_key_type这个特性,还能对GIPK做点什么新花活呢?

想要知道思考题答案的小伙伴,欢迎加入 IMG 官方社区高端群 。

欢迎加入 IMG 官方社区高端VIP群 。

入群请加姜老师个人微信 82946772,并备注:码农入VIP群
IMG 官方社区高端群是订阅制的,不过也就99元/年,权当请姜老师喝杯咖啡。
在会员期间你可以享受到下面的福利:
    • 突破微信群人数500的限制,以后所有高端群小伙伴可以在一起吹水;

    • 提供 IMG 公众号每篇技术文章最后遗留问题的标准答案;

    • 技术圈的江湖八卦,比如某数据库出局某行的原委,某大V被新领导GZ;

    • IMG社区技术嘉年华大会门票5折优惠;

    • 姜老师夫妇的私密分享,包括技术、工作、投资、相亲、移民等热门话题;

    • 会员每邀请新会员入群,可以享受59元的返利(把年费赚回来😄);

往期推荐



在 Kubernetes 上跑数据库,真的没有意义么?

国产数据库,乱象丛生?

TiDB 哭晕,Snowflake 正式进军 HTAP!

刚刚,甲骨文断供 MySQL ?

MySQL ,敲响了传统商业数据库的丧钟

MySQL 单表容量 100T,怎么处理这个需求?

TiDB 估值30亿美元,是高了还是低了?


您可能也对以下帖子感兴趣

文章有问题?点此查看未经处理的缓存