私钥文件权限不合法需将属主设为mysql用户且权限设为600，目录权限不超700，并排查SELinux、systemd保护机制及磁盘空间；keyring_file仅存储密钥，不参与加解密运算。
私钥文件被 MySQL 进程读取时权限不合法怎么办
MySQL keyring_file 插件启动失败、报错 Failed to open keyring file 或 Permission denied，大概率是私钥文件（keyring_file_data 指向的路径）权限太宽松。MySQL 严格要求该文件属主必须是运行 mysqld 的用户（通常是 mysql），且不能被组或其他人读写。
- 用
chown mysql:mysql /var/lib/mysql-keyring/keyring确保属主正确 - 用
chmod 600 /var/lib/mysql-keyring/keyring关闭所有非属主访问权限 - 确认目录
/var/lib/mysql-keyring权限也不超过700，否则插件可能拒绝加载 - 如果用 systemd 启动，还要检查
ProtectHome=true或NoNewPrivileges=yes是否意外阻断了文件访问
keyring_file 插件启用后服务起不来怎么排查
常见现象是 mysqld 启动卡住、日志里反复出现 Plugin 'keyring_file' init function returned error。这不是配置语法错，而是插件初始化阶段校验失败。
- 先确认插件已安装：
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'keyring_file';—— 返回空说明没装，需执行INSTALL PLUGIN keyring_file SONAME 'keyring_file.so'; - 检查
keyring_file_data路径是否绝对路径，相对路径（如./keyring）会被忽略 - 确保该路径所在磁盘有足够空间，插件会在首次写密钥时尝试扩展文件，空间不足会静默失败
- 若启用了 SELinux，
audit2why -a可能显示avc: denied { read } for comm="mysqld" path="/var/lib/mysql-keyring/keyring"，需补策略或临时设为 permissive
keyring_file 和 keyring_encrypted_file 选哪个
keyring_file 存明文 JSON，keyring_encrypted_file 加密存储——但加密密钥仍得存在本地，只是多一道混淆。别指望它防住 root 权限攻击者。
- 生产环境只要求“防误读”，用
keyring_file+ 严格文件权限就够了；加解密开销对性能有可测影响（尤其高并发密钥操作场景） -
keyring_encrypted_file需额外配置keyring_encrypted_file_password，这个密码一旦丢失，所有密钥永久不可恢复 - MySQL 8.0.30+ 默认禁用
keyring_encrypted_file，官方文档明确标注为 legacy，新项目别碰 - 真正需要加密的场景，应该上
keyring_okv（对接企业级密钥管理服务）或keyring_aws
密钥写入后为什么 SELECT ENCRYPT() 不生效
不是插件没起作用，而是 keyring_file 只管密钥存储，不参与加解密运算。MySQL 内部函数如 AES_ENCRYPT()、表加密（ENCRYPTION='Y'）才真正调用 keyring 提供的密钥。
- 验证 keyring 是否生效：执行
SELECT keyring_key_generate('mykey', 'AES', 256);，再查SELECT keyring_key_fetch('mykey');能返回二进制数据才算通 - 表级加密依赖密钥名匹配：建表时
ENCRYPTION_KEY_ID = 1对应的是 keyring 里名为secret_key_1的密钥，名字不一致就 fallback 到默认密钥 - 密钥名区分大小写，且不能含空格或特殊字符，
my-key和my_key是两个密钥 - 重启 mysqld 后，
keyring_file会重新加载文件内容，但运行中生成的密钥不会自动持久化——必须显式调用keyring_key_store()
最常被忽略的一点：keyring 插件只在服务启动时读一次文件，后续改文件内容完全无效；所有密钥增删都得通过 SQL 接口操作，而不是直接编辑 JSON 文件。
