首页 > 其他分享 >自打有了GIPKs,DBA和开发再也不用battle了

自打有了GIPKs,DBA和开发再也不用battle了

时间:2023-07-17 10:03:23浏览次数:37  
标签:GIPKs DBA greatsql id battle t1 主键 row

    1. GIPKs特性简介
    1. GIPKs特性的作用
    1. 玩转GIPKs

GIPKs解决了历史难题

1. GIPKs特性简介

从MySQL 8.0.30开始,新引入一个叫做GPIKs的特性,其全称是 Generated Invisible Primary Keys,简言之就是 自动生成隐含的主键列,更完整的说法是:启用GIPKs后,当新建的InnoDB表没有显式主键时,会自动创建一个不可见的主键列 my_row_id,这个列会被定义为 bigint unsigned NOT NULL AUTO_INCREMENT,并且是不可见的(INVISIBLE)。

2. GIPKs特性的作用

实际上这个特性在有些分支版本上早就已经实现了,这个需求也是非常迫切,MySQL官方对这个特性的支持虽迟但到,积极意义还是很大滴,解决了几个历史难题:

  1. DBA无需再和开发battle,强调一定要有显式自增主键列。当然了,个别情况下非要显式指定非自增列(例如选择UUID/VARCHAR类型列)做主键的,DBA也无可奈何啊。
  2. 在MGR架构中,也不用要求每个InnoDB表都必须要有显式定义的主键列。

上述这两种情况下,都可以从GIPKs特性中获益,会自动创建隐含的 my_row_id 主键列。

GIPKs特性带来的一点点不便是,当我们想要显式创建一个名为 my_row_id 的列名时,会报错,不让创建,因为被GIPKs特性给当做保留关键字了,例如:

greatsql> create table t2(
id bigint unsigned not null auto_increment,
my_row_id int NOT NULL);
ERROR 4109 (HY000): Failed to generate invisible primary key. Auto-increment column already exists.

需要注意的是,在传统主从复制或MGR架构中,GIPKs特性的设置值不会被复制到从节点,仅影响当前节点。不过,这完全不影响主从复制或MGR的正常工作,也就是说:在主节点上创建无显式定义主键列的表数据,可以正常复制到从节点。前提条件是设置 binlog_format = row,在MGR中,要求binlog必须采用row格式。

另外,mysqldump 中也相应增加了新选项 --skip-generated-invisible-primary-key,用于指定备份时是否要忽略隐含主键列。

3. 玩转GIPKs

下面我们在MGR环境中举栗说明怎么玩转GIPKs特性:

# 当前使用 GreatSQL 8.0.32-24 版本
greatsql> \s
..
Server version:  8.0.32-24 GreatSQL, Release 24, Revision 3714067bc8c
...

# 在MGR环境中测试
greatsql> select * from performance_schema.replication_group_members;
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| CHANNEL_NAME              | MEMBER_ID                            | MEMBER_HOST   | MEMBER_PORT | MEMBER_STATE | MEMBER_ROLE | MEMBER_VERSION | MEMBER_COMMUNICATION_STACK |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+
| group_replication_applier | 2adec6d2-febb-11ed-baca-d08e7908bcb1 | 192.168.5.160 |        3307 | ONLINE       | SECONDARY   | 8.0.32         | XCom                       |
| group_replication_applier | 2f68fee2-febb-11ed-b51e-d08e7908bcb1 | 192.168.5.160 |        3308 | ONLINE       | ARBITRATOR  | 8.0.32         | XCom                       |
| group_replication_applier | 5e34a5e2-feb6-11ed-b288-d08e7908bcb1 | 192.168.5.160 |        3306 | ONLINE       | PRIMARY     | 8.0.32         | XCom                       |
+---------------------------+--------------------------------------+---------------+-------------+--------------+-------------+----------------+----------------------------+

# 确认启用GIPKs特性
greatsql> show variables like 'sql_generate_invisible_primary_key';
+------------------------------------+-------+
| Variable_name                      | Value |
+------------------------------------+-------+
| sql_generate_invisible_primary_key | ON    |
+------------------------------------+-------+

# 新建表,未显式指定主键列
greatsql> create table t1 ( id int not null, c1 varchar(10) not null, unique key(id));

greatsql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `my_row_id` bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,
  `id` int NOT NULL,
  `c1` varchar(10) NOT NULL,
  PRIMARY KEY (`my_row_id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

可以看到,在建表时已经创建了唯一索引列(该索引列可以被选用作聚集索引),但由于没显式指定主键索引,所以还是会创建一个隐含的主键列 my_row_id,这个隐含的主键列默认是不可见的,除非我们手动修改其可见性。

# 即便是 SELECT *,也无法读取隐含的主键列
greatsql> select * from t1;
+----+----+
| id | c1 |
+----+----+
|  1 | c1 |
|  2 | c2 |
+----+----+

# 除非修改隐含主键列为可见
greatsql> alter table t1 alter column my_row_id set visible;

# 这时就能看到这个隐含主键列
greatsql> select * from t1;
+-----------+----+----+
| my_row_id | id | c1 |
+-----------+----+----+
|         1 |  1 | c1 |
|         2 |  2 | c2 |
+-----------+----+----+

# 再次查看表结构
greatsql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `my_row_id` bigint unsigned NOT NULL AUTO_INCREMENT,
  `id` int NOT NULL,
  `c1` varchar(10) NOT NULL,
  PRIMARY KEY (`my_row_id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

# 还可以再次将其设置为不可见
greatsql> alter table t1 alter column my_row_id set invisible;

greatsql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `my_row_id` bigint unsigned NOT NULL AUTO_INCREMENT /*!80023 INVISIBLE */,
  `id` int NOT NULL,
  `c1` varchar(10) NOT NULL,
  PRIMARY KEY (`my_row_id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

如果不想继续使用该隐含列作为主键,可以执行类似下面的SQL命令进行修改:

# 删除隐含主键列、主键,并新建自定义的主键列
greatsql> alter table t1 drop column my_row_id, drop primary key, add aid bigint unsigned not null auto_increment primary key first;

# 再次查看表结构和查询表数据
greatsql> show create table t1\G
*************************** 1. row ***************************
       Table: t1
Create Table: CREATE TABLE `t1` (
  `aid` bigint unsigned NOT NULL AUTO_INCREMENT,
  `id` int NOT NULL,
  `c1` varchar(10) NOT NULL,
  PRIMARY KEY (`aid`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci

greatsql> select * from t1;
+-----+----+----+
| aid | id | c1 |
+-----+----+----+
|   1 |  1 | c1 |
|   2 |  2 | c2 |
+-----+----+----+

可以看到,GIPKs特性还是很灵活实用的。

P.S,最新发布的GreatSQL 8.0.32-24版本中,已经包含了该特性,可以放心使用。

全文完。

Enjoy GreatSQL

标签:GIPKs,DBA,greatsql,id,battle,t1,主键,row
From: https://www.cnblogs.com/greatsql/p/17559201.html

相关文章

  • 【Netty】「优化进阶」(二)浅谈 LengthFieldBasedFrameDecoder:如何实现可靠的消息分割?
    前言本篇博文是《从0到1学习Netty》中进阶系列的第二篇博文,主要内容是通过不同的应用案例来了解LengthFieldBasedFrameDecoder是如何处理不同的消息,实现自动分割,往期系列文章请访问博主的Netty专栏,博文中的所有代码全部收集在博主的GitHub仓库中;介绍LengthFieldBasedFrameDe......
  • Netty-LengthFieldBasedFrameDecoder-解决拆包粘包问题的解码器
    LengthFieldBasedFrameDecoder的构造器参数中包括:maxFrameLength:指定解码器所能处理的数据包的最大长度,超过该长度则抛出TooLongFrameException异常。lengthFieldOffset:指定长度字段的起始位置。lengthFieldLength:指定长度字段的长度。lengthAdjustment:指定长度字段所表示......
  • dba+开源工具:面向开发的Redis轻便式图形可视化监控工具(附下载)
    轻便式RedisMonitor是面向研发人员的图形可视化监控工具,借鉴了LEPUS(天兔)监控平台以及redis-cliinfo命令输出的监控指标项,去掉了一些不必要、看不懂的监控项,目前采集了数据库连接数、QPS、内存使用率统计和同步复制延迟时长。RedisMonitor可以监控单机模......
  • 行业DBA走进华为,共建数据库生态
    近日,华为联合新意科技、掌数科技在华为东莞松山湖基地共同举办了“证券、基金行业DBA走进华为——GaussDB赋能培训”活动。本次培训有近30家证券、基金等行业机构的DBA积极参与,旨在分享华为自身GaussDB数据库经验,帮助客户用好数据库,与伙伴建立深度合作,共同打造数据库生态,推动数据库......
  • No Feign Client or loadBalanced defined
     创建consumer通过feign调用provider服务时报错一开始是Controller里@Autowired爆红,无法识别EchoService在主启动类中添加@EnableFeignClient后红线消失但运行后出现上面图中的错误百度一下后得知SpringCloudFeign在Hoxton.M2RELEASED版本之后不再使用ribbon(看的教程里教......
  • PANDACU: Second Hand Brand Bags Used Handbag Brand Purse Shoulder Bags Wholesale
    PANDACUisatrustedwholesalesupplierspecializinginsecond-handbrandbags,includingusedhandbagsandbrandpurses.Theyofferawiderangeofoptionsforretailers,resellers,anddistributorsseekinghigh-qualityshoulderbagsatwholesaleprices.......
  • 数据库上云就可以 解雇 DBA ,来说说数据库上云那些 “有意思” 的事情
    随着问问题的同学越来越多,公众号内部私信回答问题已经很困难了,所以建立了一个群,关于各种数据库的问题都可以,目前主要是POSTGRESQL,MYSQL,MONGODB,POLARDB,REDIS等,期待你的加入,另外针对云的问题,我们可以多多交流互相学习————————————————————————正文......
  • DBA 会点架构 做一个有文化的 “不服就干
    开头还是介绍一下群,如果感兴趣polardb,mongodb,mysql,postgresql,redis等有问题,有需求都可以加群群内有各大数据库行业大咖,CTO,可以解决你的问题。这里假设,你不是一个DB,你是一个开发,一个架构,你怎么看DB我来简单的列举一下1管数据库的SB 2就会审核个SQL,连看都不看SB3就会唠......
  • PG-DBA培训03:Linux平台PostgreSQL安装配置与管理入门
    一、风哥PG-DBA培训03:Linux平台PostgreSQL安装配置与管理入门本课程由风哥发布的基于PostgreSQL数据库的系列课程,本课程属于PostgreSQL数据库实战入门与安装配置阶段之Linux平台PostgreSQL安装配置与管理入门课程,学完本课程可以掌握基于Linux平台的PostgreSQL项目规划,PostgreSQL......
  • PG-DBA培训02:Win平台PostgreSQL安装配置与管理入门 原创
    一、风哥PG-DBA培训02:Win平台PostgreSQL安装配置与管理入门本课程由风哥发布的基于PostgreSQL数据库的系列课程,本课程属于PostgreSQL数据库实战入门与安装配置阶段之Win平台PostgreSQL安装配置与管理入门课程,学完本课程可以掌握基于Windows平台的PostgreSQL项目规划,PostgreSQL数......