encryption='y' 仅是加密触发标识，真正合规依赖密钥全生命周期管理；必须配置innodb_file_per_table=on、keyring_file_data为独立安全路径并严格设权，否则加密无效且不满足等保2.0/gdpr/pci dss要求。
ENCRYPTION='Y' 这个参数本身不解决合规问题，真正起作用的是背后整套密钥生命周期管理和加密落地方式。MySQL 5.7 的 InnoDB 表空间加密功能之所以被等保2.0、GDPR、PCI DSS 等标准认可，是因为它满足了“静态数据加密（Data-at-Rest Encryption）”这一硬性要求，但前提是配置必须严格符合规范——否则只是假安全。
keyring_file.so 不等于合规，路径和权限才是关键
keyring_file_data 指向的文件不能放在 MySQL 数据目录下，也不能是可被普通用户读写的路径。一旦攻击者拿到该文件，就能解密所有 .ibd 文件。
- 必须用 chown mysql:mysql 且 chmod 750 或更严（如 600）
- 目录需独立于 datadir，最好在另一块磁盘或挂载卷上
- keyring_file_data 值不能是相对路径，必须为绝对路径，且 MySQL 启动时会自动创建该文件——如果父目录不可写，服务直接启动失败
innodb_file_per_table=1 是加密生效的前提条件
共享表空间（ibdata1）**完全不支持加密**，哪怕你对某张表加了 ENCRYPTION='Y'，只要它还在系统表空间里，就毫无意义。
- 必须确认全局变量 innodb_file_per_table 为 ON（默认值在 5.6+ 是 ON，但旧实例可能被手动关过）
- 已存在的非独立表空间表（即 CREATE TABLE ... TABLESPACE innodb_system）无法直接加密，必须先 ALTER TABLE ... ENGINE=InnoDB 触发重建到独立 .ibd
- information_schema 和 mysql 系统库下的表默认不加密，也不建议加密——它们不存业务敏感数据，且加密后可能影响升级或恢复流程
encrypt_tables=FORCE 会强制所有新表默认加密，但有隐藏风险
这个选项看似省事，实则容易踩坑： - 它只对新建表生效，不影响已有表；若忘记对存量表逐个执行ALTER TABLE ... ENCRYPTION='Y'，大量数据仍裸奔
- 如果后续要迁移表到未启用 keyring 的从库，复制会中断（因为从库无法解密页）
- encrypt_tables=FORCE 在配置中启用后，即使某张表显式指定 ENCRYPTION='N'，也会被覆盖为 'Y' ——这可能导致日志表、临时汇总表等非敏感表无谓消耗 CPU
真正容易被忽略的点在于：密钥轮换（key rotation）不是改个配置就能完成的。MySQL 5.7 不提供在线主密钥轮换命令，必须停机替换 keyring_file_data 文件并重载插件，过程中所有加密表都不可访问。而合规审计往往要求“密钥定期轮换”，这点在生产环境里常被跳过或手工操作出错。
