mysql 8.0 启用表空间加密必须预先在my.cnf中配置early-plugin-load并指定keyring_file路径，手动预置json格式主密钥，且仅对独立表空间生效；密钥文件须独立存放、同步备份，加密表不可降级。
MySQL 8.0 启用表空间加密前必须加载 keyring_file 插件
不加插件就建加密表，直接报错 ERROR 3182 (HY000): Cannot encrypt a table when the keyring plugin is not installed。这个错误不是配置漏了，而是插件根本没在启动时加载——仅执行 INSTALL PLUGIN 无效，重启后丢失。
必须在 my.cnf 的 [mysqld] 段落中写死两行：
-
early-plugin-load=keyring_file.so（Linux）或early-plugin-load=keyring_file.dll（Windows），路径可通过SELECT @@plugin_dir;确认 -
keyring_file_data=/var/lib/mysql-keyring/keyring，该路径不能是/tmp、不能是符号链接、目录需提前创建且属主为mysql
常见坑：路径权限不对（chown mysql:mysql /var/lib/mysql-keyring 忘了）、secure_file_priv 开启后插件无法写入密钥文件、MySQL 版本低于 8.0.13（早期版本有 keyring_file 写入 bug）。
主密钥不能依赖 MySQL 自动创建
MySQL 启动时若发现 keyring_file_data 文件不存在，会自动生成一个随机主密钥，但这个密钥不可控、不可备份、不可迁移。一旦文件损坏或误删，所有加密表查询返回空或乱码，SHOW CREATE TABLE 却仍显示 ENCRYPTION='Y'，极难排查。
正确做法是手动预置主密钥：
- 用
openssl rand -hex 32生成 64 字符 hex 字符串（对应 AES-256） - 将密钥写入
keyring_file_data文件，格式为严格 JSON（注意引号、换行、字段名）：
{
"key": "a1b2c3d4e5f678901234567890abcdef1234567890abcdef1234567890abcdef",
"id": "master-key-1",
"type": "AES"
}
其中 key 值替换为你生成的字符串，id 需唯一且后续轮换时不能重复。
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
加密只对独立表空间生效，且不可降级
innodb_file_per_table=1 是硬性前提。系统表空间（如 ibdata1）和通用表空间不支持加密；即使设了 ENCRYPTION='Y'，建表也不会报错，但实际不加密——INFORMATION_SCHEMA.INNODB_TABLESPACES 中 ENCRYPTION 字段为 NO。
已加密的表无法通过 ALTER TABLE ... ENCRYPTION='N' 降级。想关闭加密，只能导出数据、删表、重建未加密表再导入。这意味着加密决策要一次性拍板，不能试错。
另外：ALTER TABLE ... ENCRYPTION='Y' 是在线操作，但会触发全表重写，大表耗时长、IO 高；建议在低峰期执行，并确认磁盘剩余空间 ≥ 表大小 × 2。
备份时密钥文件必须与数据文件同步归档
物理备份（如 xtrabackup）包含加密后的 .ibd 文件，但解密依赖 keyring_file_data 中的主密钥。如果只备份数据文件，没备份密钥文件，恢复后所有加密表不可读——MySQL 不报错，只是查不到数据。
逻辑备份（如 mysqldump）导出的是明文，不受表空间加密影响，但导出文件本身需额外加密（如 gpg 或 openssl enc），否则敏感字段暴露。
最容易被忽略的一点：密钥文件本身不能放在数据库数据目录下。它必须独立存放、独立权限控制、独立备份策略——和 my.cnf、SSL 证书一样，属于“基础设施密钥”，不是普通配置文件。
