MySQL 8.4 表空间加密怎么核对：密钥环、表加密与重启后状态

给 InnoDB 表打开加密后，真正需要验收的不是一条 ALTER TABLE 是否返回成功，而是密钥环、表空间元数据和重启恢复能不能连成一条闭环。MySQL 8.4 把表空间密钥写入表空间头部，再用密钥环管理主加密密钥；密钥环没有在存储引擎初始化前加载，重启或恢复时就可能直接失败。

稳妥的核对顺序是：确认只启用了一个可用的 keyring 组件，确认 INNODB_TABLESPACES.ENCRYPTION 为 Y，再在维护窗口做受控重启；只看到 DDL 成功，不能证明灾备恢复链路完整。

先分清主密钥、表空间密钥和数据页

InnoDB 使用两层密钥。表空间密钥负责实际数据页的加解密，它的加密版本保存在表空间头部；主加密密钥由 keyring 管理，用来保护表空间密钥。执行 ALTER INSTANCE ROTATE INNODB MASTER KEY 时，轮换的是主加密密钥和表空间密钥的保护方式，不是把全部数据页重新加密一遍。

这个区别很重要：轮换主密钥的影响面是密钥元数据，给现有文件表空间启用加密则会重建表。MySQL 官方说明中，file-per-table 表空间改变加密属性会使用 ALGORITHM=COPY；通用表空间使用 INPLACE，但并发 DDL 仍会受到影响。

启用前先核对 keyring 和默认策略

首次启用前，先在实例启动配置中确认只加载一个 keyring 组件，并确认它的配置文件和数据文件位于可备份、权限受控的位置。示例使用官方提供的 component_keyring_file，它适合演示核对路径；合规场景是否需要集中式密钥管理，要按组织的安全要求另行评估。

SHOW VARIABLES LIKE 'default_table_encryption';
SELECT PLUGIN_NAME, PLUGIN_STATUS
FROM INFORMATION_SCHEMA.PLUGINS
WHERE PLUGIN_NAME LIKE '%keyring%';

如果返回结果看不出当前组件，不要急着执行加密 DDL，先核对启动参数、错误日志和 performance_schema.keyring_component_status。default_table_encryption 只影响没有显式写 ENCRYPTION 的新 schema 或通用表空间；修改已有对象时仍要显式指定。

用元数据确认真正被加密的对象

创建一个专门用于演练的 file-per-table 表空间或表，显式写出加密选项，避免把 schema 默认值误认为对象最终状态。

CREATE DATABASE IF NOT EXISTS encryption_lab;
CREATE TABLE encryption_lab.orders (
  id BIGINT PRIMARY KEY,
  amount DECIMAL(12,2) NOT NULL
) ENGINE=InnoDB ENCRYPTION='Y';

SELECT SPACE, NAME, SPACE_TYPE, ENCRYPTION
FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE NAME = 'encryption_lab/orders';

SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS
FROM INFORMATION_SCHEMA.TABLES
WHERE TABLE_SCHEMA = 'encryption_lab'
  AND TABLE_NAME = 'orders';

第一条查询用于确认 InnoDB 表空间层面的 ENCRYPTION 是否为 Y；第二条查询用于确认建表语句记录的 CREATE_OPTIONS。两处都出现加密信息，核对才比较完整。若表位于通用表空间，还要继续查询它所在的通用表空间，而不是只看表名。

主密钥轮换和表空间改密不是一回事

有些变更窗口只需要轮换主密钥，有些则是给未加密数据表迁移到加密表空间。两者不要混在同一条变更记录里。

主密钥轮换中途遇到服务器故障时，InnoDB 会在重启后继续处理；这并不等于可以删除旧 keyring 数据文件。密钥备份和轮换记录必须作为恢复材料保留下来。

受控重启要看什么才算通过

最后一步放在维护窗口完成。重启前记录当前 keyring 配置、加密表空间清单和错误日志位置；重启后先看实例是否正常进入可服务状态，再重新执行元数据查询。component_keyring_file 在创建加密表空间时使用过，就必须继续在启动阶段加载。

SELECT SPACE, NAME, ENCRYPTION
FROM INFORMATION_SCHEMA.INNODB_TABLESPACES
WHERE ENCRYPTION = 'Y';

SELECT SCHEMA_NAME, DEFAULT_ENCRYPTION
FROM INFORMATION_SCHEMA.SCHEMATA
WHERE DEFAULT_ENCRYPTION = 'YES';

可见成功状态包括：MySQL 完成启动、加密表空间查询仍返回目标对象、业务账号能读取测试行、错误日志没有 keyring 初始化或 InnoDB 恢复错误。只要其中一项不满足，就先停止流量切换或回滚变更，不要用“服务端口已打开”代替数据可读性验证。

常见问题：MySQL 8.4 表空间加密的回退边界

只备份数据库文件，不备份 keyring，可以恢复吗？

不能把它当成完整恢复方案。主加密密钥保存在数据库之外，丢失后加密表空间文件不可恢复；数据库文件和 keyring 数据必须按同一恢复策略保护。

关闭加密后能立刻移除 keyring 吗？

不能直接这样推断。官方说明要求已有加密数据、redo 或 undo 仍被使用时继续提供对应 keyring；先按实例实际加密范围和清理步骤核验。

轮换主密钥会让所有大表重写吗？

不会。轮换重加密的是表空间密钥的保护信息；要改变表空间数据的加密状态，才需要执行对应的表或表空间变更。

上线前的最小检查清单

• 启动配置只启用一个 keyring 组件，配置文件和 keyring 数据已有可恢复备份。
• 目标表或表空间在 INNODB_TABLESPACES 中的 ENCRYPTION 值符合设计，表级记录也已复核。
• 变更账号具备所需权限，且已评估 COPY 重建、锁和磁盘空间影响。
• 重启后能读取测试数据，错误日志、加密清单和轮换记录已归档。

把这四项连在同一张变更单里，才算完成一次可恢复的 MySQL 8.4 表空间加密验收。