用导出选项控制 GIPK 是否写入备份并核对恢复后的表结构

如果源表带有生成不可见主键（GIPK），用 mysqldump 做逻辑备份时，关键不是“能不能导出”，而是要先决定这条辅助主键是否应该进入备份。默认情况下，导出会保留 GIPK；加入 --skip-generated-invisible-primary-key 后，生成不可见主键会从导出内容中排除。完整迁移通常保留它，面向业务字段的样本库或结构对照则可以排除。

MySQL 8.4 官方资料：https://dev.mysql.com/doc/refman/8.4/en/mysqldump.html

把“导出选项”与“恢复后核对”配成一对：命令决定备份里写什么，目标库上的 DDL 和列元数据决定最终恢复了什么。

先区分保留与排除两种结果

GIPK 的特殊之处在于，它是表结构中的主键，但不属于通常展示给业务开发者的可见列。备份时如果直接沿用默认命令，生成不可见主键会写入逻辑导出；如果目标是保留源表的完整结构，这正是需要的结果。

当备份用于脱敏样本、业务字段清单或跨环境结构对照时，系统辅助列可能不应出现在导出文件里。此时使用 --skip-generated-invisible-primary-key，让导出内容不包含 GIPK。该选项的默认值是 FALSE，所以不能把“没有写选项”理解成“自动排除”。

确认源表中的业务列和 GIPK

先在源库记录表结构，再决定导出策略。这里的重点不是手工改表，而是把“源表本来有什么”作为恢复后对照基线。示例使用一个没有显式业务主键的订单草表，列名仅用于说明核对方法。

-- 记录源表 DDL，先看表结构再决定备份选项
SHOW CREATE TABLE demo_orders;

-- 列出字段的可见性和主键标记，避免只凭 SELECT * 判断
SELECT
    COLUMN_NAME,
    ORDINAL_POSITION,
    COLUMN_KEY,
    EXTRA,
    IS_VISIBLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'demo'
  AND TABLE_NAME = 'demo_orders'
ORDER BY ORDINAL_POSITION;

查询结果要区分业务字段和系统辅助字段。业务字段可以是订单号、状态和创建时间；GIPK 则是为表提供主键能力的不可见列。后续比较时，要把“列是否存在”“是否不可见”“是否为主键”分别记录，不能只比较可见列数量。

分别生成两种逻辑备份

下面用同一个源表生成两份备份，唯一变化是是否加入排除选项。连接参数、数据库名和表名应替换为实际值；示例不把密码写在命令行里，避免进入 shell 历史记录。

# 默认导出：按完整结构迁移的思路保留 GIPK
mysqldump --single-transaction demo demo_orders \
  --result-file=demo_orders-with-gipk.sql

# 业务字段样本：排除生成不可见主键
mysqldump --single-transaction \
  --skip-generated-invisible-primary-key \
  demo demo_orders \
  --result-file=demo_orders-without-gipk.sql

官方文档把 --skip-generated-invisible-primary-key 定义为“不把生成不可见主键写入输出”。它只改变逻辑导出的结构内容，不是删除源表主键，也不是修改源库的表定义。实际批处理时，建议把使用的选项连同备份文件名一起记录，避免恢复人员只拿到一个没有上下文的 SQL 文件。

恢复到独立目标库

导出完成后，要把文件恢复到独立的目标库或临时 schema，再观察恢复结果。直接在源库查询无法证明导出文件是否包含 GIPK，因为源库本身没有被这条命令修改。

# 创建两个目标库，分别承接保留和排除两种备份
mysql -e "CREATE DATABASE IF NOT EXISTS demo_restore_keep"
mysql -e "CREATE DATABASE IF NOT EXISTS demo_restore_skip"

# 导入保留 GIPK 的备份
mysql demo_restore_keep 

恢复命令的作用只是把 SQL 文件执行到目标库；它不会替你解释“为什么列数量不同”。因此，两个目标库应使用不同的库名，后续对照才不会把一次导入的结果覆盖掉。

用 DDL 和元数据核对结构

恢复后先看 SHOW CREATE TABLE，再查 INFORMATION_SCHEMA.COLUMNS。前者适合快速阅读完整建表语句，后者适合把两个目标库放在同一张对照表里。

-- 分别输出两个目标库的建表语句，重点关注主键和不可见列
SHOW CREATE TABLE demo_restore_keep.demo_orders;
SHOW CREATE TABLE demo_restore_skip.demo_orders;

-- 统一抽取两个版本的列元数据，便于逐项对照
SELECT
    TABLE_SCHEMA,
    COLUMN_NAME,
    ORDINAL_POSITION,
    COLUMN_KEY,
    EXTRA,
    IS_VISIBLE
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA IN ('demo_restore_keep', 'demo_restore_skip')
  AND TABLE_NAME = 'demo_orders'
ORDER BY TABLE_SCHEMA, ORDINAL_POSITION;

如果两个目标库的业务列一致，但主键元数据不同，通常正是导出选项造成的差异。核对时不要只打开 SQL 文件搜索某个列名，也不要只看导入是否成功；能执行并不等于结构与预期相同。

兼容注意：选项由客户端版本决定

mysqldump 是客户端程序，支持哪些选项要以实际客户端的 --help 输出为准。把带有 GIPK 选项的脚本交给较旧客户端前，先确认它能识别该选项；如果客户端直接报未知参数，应先调整工具链，不要删掉选项后继续假设导出结果相同。

# 查看当前 mysqldump 是否支持 GIPK 排除选项
mysqldump --help | grep generated-invisible-primary-key

# 保存客户端版本，便于以后解释备份命令的行为
mysqldump --version

此外，完整迁移和业务样本是两种不同目标。前者更关心源表结构的完整复现，后者更关心字段边界和可读性。不要为了让导出文件看起来更简单，就在完整迁移中随意排除系统辅助主键；也不要把样本库的导出策略反过来当成生产恢复策略。

常见问题

不写任何 GIPK 选项时会发生什么？

官方文档给出的该选项默认值是 FALSE，因此默认导出不会排除生成不可见主键。是否保留仍应通过恢复后的 DDL 和元数据确认。

--skip-generated-invisible-primary-key 会修改源表吗？

不会。它作用于 mysqldump 输出，源库表定义不会因为生成备份而被删除或改写。

只查看业务查询结果能确认 GIPK 是否恢复吗？

不能。不可见列不适合用普通的可见列查询来判断，应该结合 SHOW CREATE TABLE 和 INFORMATION_SCHEMA.COLUMNS 的主键、可见性等元数据。

恢复成功但结构不符合预期怎么办？

先记录使用的 mysqldump 客户端版本、完整选项和目标库名称，再重新检查 DDL 与列元数据。不要直接覆盖目标库，以免丢失第一次恢复的对照结果。

小结

控制 GIPK 是否进入备份，核心只有两个动作：用默认导出保留完整结构，或用 --skip-generated-invisible-primary-key 排除生成不可见主键。真正决定结果的不是命令是否返回成功，而是恢复到独立目标库后，能否从建表语句和列元数据中核对出符合用途的结构。