没有主键的 InnoDB 表为何出现 my_row_id：GIPK 复制与备份边界

一次 MySQL 8.4 迁移验收的过程中，明明表结构定义里没写 PRIMARY KEY，执行 SHOW CREATE TABLE 却多出来一个 my_row_id 列。这不是客户端偷偷改了SQL，而是服务端开了 sql_generate_invisible_primary_key 参数，自动给没设显式主键的InnoDB表补了个不可见主键。排查的重点不是上来就把它删掉，得先搞清楚它是在哪步生成的、会不会同步到副本、备份里有没有带，再敲定新老表的迁移方案。

只要开关设为ON，且新建的是没有显式主键的InnoDB表，MySQL 8.4就会生成名为my_row_id的不可见列和对应主键；它不会出现在SELECT *的返回结果里，但会直接影响表定义、复制逻辑和备份恢复的正确性。

先把“多出来的主键”复现出来

先用隔离的测试实例或者测试库确认开关状态。生产环境只用只读查询校验就行，别为了验证直接修改全局变量。

SELECT @@GLOBAL.sql_generate_invisible_primary_key,
       @@SESSION.sql_generate_invisible_primary_key;

SET SESSION sql_generate_invisible_primary_key = ON;

CREATE TABLE order_events (
  event_type VARCHAR(32) NOT NULL,
  payload JSON NOT NULL,
  created_at TIMESTAMP NOT NULL
) ENGINE = InnoDB;

这张表完全没写显式主键，当会话级别的开关设为ON时，服务端就会自动生成隐藏的BIGINT UNSIGNED自增列my_row_id，同时把它设为主键。这个判断逻辑只在建表的时候触发；就算建完表把变量改回OFF，已经生成的隐藏列也不会自动移除。

用三个证据确认它是不是GIPK

别只靠SELECT *的返回结果下结论。不可见列不会被星号查询带出，得通过表定义、列属性、索引信息三个维度去核对。

SHOW CREATE TABLE order_events\G
SHOW COLUMNS FROM order_events;
SHOW INDEX FROM order_events;

SELECT COLUMN_NAME, EXTRA, IS_VISIBLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = DATABASE()
  AND TABLE_NAME = 'order_events';

如果校验结果同时满足以下几个条件，基本就能确定是自动生成的GIPK：

• 表的存储引擎是InnoDB，且整个表没有业务层面声明的PRIMARY KEY。
• 存在名为my_row_id的不可见列，默认带自增属性。
• 执行SHOW INDEX能查到同名的主键索引，但普通的SELECT *查询完全看不到这一列。

这个自动生成的主键依然会参与InnoDB的行定位和约束判断，不是只存在于元数据里的标记，绝对不能把它当成业务订单号、事件号或者跨系统使用的稳定ID。

迁移时最容易踩中的三个边界

源库开了开关，不等于副本会自动同步开开关

sql_generate_invisible_primary_key这个参数不会通过普通的主从复制同步给副本。已经写入binlog的建表语句会不会带出自动生成的主键结果，要结合当前的复制格式和具体语句单独验收，不能只查副本上的同名变量就下结论。

有复制链路的表，验收顺序推荐这么走：源库执行建表语句，先检查源库的SHOW CREATE TABLE结果，等副本完成日志回放，再去副本上检查表定义和主键列状态。如果源库有这个主键、备库没有，先直接暂停发布流程，别手动用ALTER去“补全”主键，不然会把复制链路的语义问题直接掩盖掉。

CREATE TABLE ... SELECT 不能按普通建表想当然

批量迁移经常会用CREATE TABLE new_events AS SELECT ...这类语句。打开GIPK开关之后，MySQL 8.4对这类语句的复制逻辑有额外限制：行格式复制可以把自动生成的主键定义同步过去，语句格式复制则不允许在开关开启时执行这类CTAS语句。迁移脚本要先核对当前的binlog_format，再在和生产完全一致的复制拓扑里做一次全流程跑通测试。

列名my_row_id可能和老的DDL冲突

开关开启后，如果本来没写显式主键的建表语句里自己已经声明了名为my_row_id的列，就会和服务端自动生成列的命名规则冲突。最稳妥的处理方式是直接给表补上合理的业务主键；如果这个字段只是历史遗留下来的无用字段，也要先评估重命名操作对ORM、导入脚本和报表服务的影响。

备份和恢复要按“是否保留GIPK”验收

用mysqldump做备份的时候，默认配置会把自动生成的不可见主键定义和对应数据都写到导出文件里。如果迁移目标环境希望重新生成隐藏主键，而不是直接把源库的隐藏列原样搬过去，得显式加上--skip-generated-invisible-primary-key参数，导入到目标端之后再重新核对表定义。

# 保留源库生成的主键：按默认导出后核对 CREATE TABLE
mysqldump app_db order_events > order_events.sql

# 不把 GIPK 信息写入导出：目标端按自己的开关决定
mysqldump --skip-generated-invisible-primary-key \
  app_db order_events > order_events-without-gipk.sql

两种选择没有绝对的好坏，保留GIPK适配源端目标端结构完全一致的迁移需求，跳过GIPK适配把老表定义交给目标环境自行处理的场景，但一定要避免目标端导入后出现完全没有主键的InnoDB表。

一份可以落到发布单里的验收清单

1. 记录源库和目标库的@@sql_generate_invisible_primary_key参数值，区分全局级别和会话级别的配置。
2. 对所有没有显式主键的InnoDB表，分别留存SHOW CREATE TABLE和SHOW INDEX的查询结果。
3. 确认业务代码不会依赖SELECT *返回隐藏列，也没有把my_row_id当成对外暴露的ID使用。
4. 如果迁移流程包含CTAS操作或者主从复制链路，要按实际的binlog_format在完全相同的拓扑环境下测试建表和日志回放流程。
5. 明确备份命令有没有加--skip-generated-invisible-primary-key参数，恢复完成之后重新校验所有表的主键约束。
6. 发现两边结构不一致的时候先停止切流，保留原始DDL、变量值和复制位点信息，再做可回退的修正操作。

相关问题

GIPK会给已经存在的旧表补主键吗？

不会。它只会影响开关打开之后新建的、没有显式主键的InnoDB表；存量的老表要补主键得单独设计执行对应的ALTER语句。

my_row_id能不能直接改成可见？

可以通过ALTER COLUMN语句切换它的可见性，但操作之前得先确认ORM、导出脚本和接口响应不会突然多出一个之前没出现过的字段，通常不建议直接把它当成业务字段对外暴露。

为什么SELECT * 看不到它？

因为它本身就是不可见列。要查询它可以直接写显式列名、执行SHOW CREATE TABLE、SHOW COLUMNS或者直接查INFORMATION_SCHEMA里的对应系统表。

生产库应该一直打开这个开关吗？

要不要打开完全看你这边的主键治理规范和迁移规则。打开之前至少要统一所有节点的复制格式、备份策略、命名冲突处理方案，以及应用层和隐藏字段的边界约定。

把隐藏主键当作迁移事实，而不是业务设计

GIPK本质上是InnoDB表缺主键时的工程兜底方案，替代不了订单号、租户内序列或者事件幂等键这类业务字段。验收的时候把“开关状态、表定义、复制逻辑、备份规则”四件事串起来核对，才能确认目标库最终落地的是正确的表结构；如果业务需要可读、可传递、能跨系统关联的ID，还是要在DDL里明确定义出来。