启用InnoDB表空间加密必须开启innodb_file_per_table=ON并加载keyring_plugin；否则建表加密会静默失败。密钥环路径权限、配置顺序及插件冲突是ERROR 3185主因。
MySQL 5.7+ 启用 InnoDB 表空间加密前必须开的开关
表空间加密不是开个配置就自动生效的——innodb_file_per_table 必须为 ON，且加密密钥由 keyring_plugin 提供，这两者缺一不可。默认情况下它们全关着，直接配 ENCRYPTION='Y' 会静默失败或建表报错。
-
innodb_file_per_table=ON：否则所有表挤在系统表空间ibdata1里，无法对单个表空间加密 - 必须加载密钥环插件：
INSTALL PLUGIN keyring_file SONAME 'keyring_file.so'（Linux）或对应平台版本；keyring_file_data配置项要指向可读写的安全路径，比如/var/lib/mysql-keyring/keyring - 重启 mysqld 后检查：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME LIKE 'keyring%';确保状态是ACTIVE
给已有表加加密？ALTER TABLE 不行，得重建
MySQL 不支持直接 ALTER TABLE ... ENCRYPTION='Y' 切换加密状态。它只接受建表时指定，或对临时表/分区表做在线加密切换——但普通表只能重建。
- 导出再导入最稳：
mysqldump --no-create-info db tbl | mysql db配合新表定义（含ENCRYPTION='Y'） - 用
CREATE TABLE ... LIKE复制结构，再INSERT INTO ... SELECT搬数据，最后DROP + RENAME；注意期间锁表时间长，业务需评估 - 如果用的是 MySQL 8.0.16+，可尝试
ALTER TABLE ... FORCE触发重建，但依然不保证加密生效，必须显式加上ENCRYPTION='Y'子句 - 别信
SHOW CREATE TABLE里没显示ENCRYPTION就以为没加密——查INFORMATION_SCHEMA.INNODB_TABLESPACES的ENCRYPTION字段才准
加密表空间的性能和兼容性现实
加密不是白用的：CPU 开销实打实，尤其高并发写入场景；而且备份、复制、升级都可能卡在这儿。
- 加解密走 CPU，AES-128-CBC 模式下 QPS 下降约 5–15%，SSD 延迟敏感场景更明显
-
mysqldump备份出来的是明文 SQL，不带加密属性；恢复后表默认不加密，得手动补ENCRYPTION='Y' - 主从复制没问题，但从库必须同样启用
keyring_plugin，否则启动时报错：Plugin 'keyring_file' is not loaded - 跨版本升级（如 5.7 → 8.0）前务必验证密钥环路径权限和插件兼容性，8.0 默认用
keyring_encrypted_file，老配置可能不认
ERROR 3185：Keyring plugin failed to store key 错在哪
这个错基本锁定在密钥环初始化阶段，不是表语法问题，而是插件根本没存进密钥——常见于权限、路径、配置顺序三处。
-
keyring_file_data路径目录不存在，或 MySQL 进程用户（如mysql）无写权限 - 配置文件里
early-plugin-load=keyring_file.so没加，或加在了[mysqld]段落之后（必须在服务启动早期加载） - 多个密钥环插件共存冲突，比如同时加载
keyring_file和keyring_okv，MySQL 只认第一个 - 密钥已存在但被标记为“过期”，此时
SELECT * FROM performance_schema.keyring_keys;能看到状态，需先DELETE再重试建表
真正麻烦的从来不是加那行 ENCRYPTION='Y'，而是密钥环能不能活过一次重启、备份脚本会不会漏掉插件依赖、以及开发环境和生产环境的密钥路径是不是真的一致。
