MySQL 8.4 自动生成隐式主键怎么识别：sql_generate_invisible_primary_key 与表结构验收

线上把一批没有显式主键的 InnoDB 表迁到 MySQL 8.4 后，最容易漏掉的变化不是业务列，而是服务器可能替你补上的不可见主键。判断不能只看 SELECT *：先确认 sql_generate_invisible_primary_key 的会话值，再用 SHOW CREATE TABLE 验收表定义，才能知道 my_row_id 是否真的存在。

GIPK 只对开启时新建的无显式主键 InnoDB 表生效，默认关闭；它不是“所有旧表自动补主键”，也不能靠 SELECT * 判断。

先确认这张表是不是在 GIPK 影响范围内

GIPK 的边界很窄：表必须使用 InnoDB，建表语句不能包含显式主键，而且创建当时的 sql_generate_invisible_primary_key 必须为 ON。已经存在的无主键表不会因为后来改了变量就被回填。

这里别急着改全局变量。先在隔离库里复现同一条建表语句，避免把生产新表的结构变化误当成查询层问题。

用 SHOW CREATE TABLE 把不可见主键验收出来

下面的复现只使用两个普通业务列。第一张表在关闭状态下创建，第二张表在开启状态下创建；差异应该出现在实际 DDL，而不是 SELECT * 的结果里。

CREATE DATABASE IF NOT EXISTS gipk_lab;
USE gipk_lab;

SET SESSION sql_generate_invisible_primary_key = OFF;
CREATE TABLE auto_0 (c1 VARCHAR(50), c2 INT) ENGINE=InnoDB;

SET SESSION sql_generate_invisible_primary_key = ON;
CREATE TABLE auto_1 (c1 VARCHAR(50), c2 INT) ENGINE=InnoDB;

SHOW CREATE TABLE auto_0;
SHOW CREATE TABLE auto_1;
SHOW INDEX FROM auto_1;

验收时重点找三处：my_row_id bigint unsigned NOT NULL AUTO_INCREMENT、列后的 INVISIBLE 标记，以及 PRIMARY KEY (my_row_id)。如果只看到 c1 和 c2，不能据此断言没有主键，必须看完整的 SHOW CREATE TABLE。

权限边界：能查到表结构，不代表能随意改 GIPK

排查账号至少需要能读取目标库的表元数据，并能执行对应的结构查询。生产环境不要为了“看一眼”直接授予全局写权限；把诊断和改表分开，先用只读账号完成核对，再由变更账号处理显式主键设计。

生成的主键列默认不可见，但它仍然是表定义的一部分。my_row_id 不能被当成业务编号，也不要在应用 SQL 中假设它会出现在 SELECT * 中。确实需要查看时，显式选择列名：

SELECT my_row_id, c1, c2
FROM auto_1
ORDER BY my_row_id;

复制与备份：不要只看源端的会话变量

sql_generate_invisible_primary_key 不会按普通会话变量那样被复制。复制链路中的 replica applier 默认不会因为源端开关为 ON 就替副本生成同名 GIPK；因此复制链路要以副本真实的表定义和复制参数为证据。

需要核对复制时，分别在 source 和 replica 执行 SHOW CREATE TABLE，再检查通道是否显式配置了 REQUIRE_TABLE_PRIMARY_KEY_CHECK = GENERATE。不要把源端的 SELECT @@GLOBAL.sql_generate_invisible_primary_key 当成副本最终结构证明。

逻辑备份也要提前定策略：如果使用 mysqldump，--skip-generated-invisible-primary-key 可以让输出排除生成的不可见主键信息。这个选项会改变恢复后的表定义，启用前先明确目标库是否需要保留 InnoDB 的主键结构。

发布前的最小检查清单

1. 记录建表会话的 @@SESSION.sql_generate_invisible_primary_key。
2. 确认目标表的存储引擎为 InnoDB，且原始建表语句没有显式 PRIMARY KEY。
3. 在 source、replica 分别保存 SHOW CREATE TABLE 和 SHOW INDEX 输出。
4. 检查应用、导出脚本和 schema diff 是否会误把 my_row_id 当业务字段。
5. 若要改变可见性，只做明确的 ALTER COLUMN my_row_id SET VISIBLE/INVISIBLE 变更，并保留回退记录。

相关问题

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

不会。它在符合条件的新建 InnoDB 表时生成；旧表需要单独设计并执行结构变更。

为什么 SELECT * 看不到 my_row_id？

因为该列是不可见列。要确认它是否存在，应看 SHOW CREATE TABLE 或显式选择 my_row_id。

副本为什么没有跟源端一样的 GIPK？

源端变量不会简单复制给 applier。应检查副本的真实 DDL，以及复制通道是否配置了生成主键的要求。

生成的主键能直接删除吗？

不能把它当普通列随意删除；需要先设计新的主键，保证变更后表仍满足主键约束，再按变更窗口执行。

把“隐藏”当成实现细节，而不是业务契约

GIPK 适合在缺少主键的 InnoDB 表上提供结构兜底，但它不会替业务建模，也不会自动解决复制、备份和 schema diff 的差异。真正上线前，至少把会话开关、完整 DDL、复制副本和备份选项放在同一份验收记录里。