MySQL 8.4 隐式生成主键怎么排查：sql_generate_invisible_primary_key 与迁移验收

一次 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 时，服务端会生成隐藏的 my_row_id BIGINT UNSIGNED AUTO_INCREMENT，并把它设为主键。开关是在建表时判断的；把变量改回 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 能看到同名主键，而普通查询不显示该列。

这个主键仍然参与 InnoDB 的行定位和约束判断。它不是“只存在于元数据里的提示”，也不能当作业务订单号、事件号或跨系统稳定 ID 使用。

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

源库打开，不等于副本自动打开

sql_generate_invisible_primary_key 不会通过普通复制设置同步给副本。已经写入二进制日志的建表语句是否包含生成结果，要结合复制格式和具体语句验收，不能只在副本上查询同名变量后下结论。

对有复制链路的表，验收顺序建议是：源库执行建表，检查源库的 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 适合希望源、目标结构一致的迁移；跳过它适合把旧表定义交给目标环境重新决定，但必须防止目标端因此得到一个完全没有主键的 InnoDB 表。

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

1. 记录源库和目标库的 @@sql_generate_invisible_primary_key，区分 GLOBAL 与 SESSION。
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 中明确声明。