MySQL表空间加密仅对新建表生效，已有表需执行ALTER TABLE ... ENCRYPTION='Y'手动触发；密钥管理、备份加密、权限隔离与密钥生命周期管理缺一不可。
MySQL表空间加密开启后为什么没生效
表空间加密（innodb_encrypt_tables=ON）默认只对新建表生效，已有表不会自动加密。哪怕你改了配置、重启了服务，INFORMATION_SCHEMA.INNODB_TABLESPACES 里 ENCRYPTION 字段还是 NO。
- 必须显式执行
ALTER TABLE tbl_name ENCRYPTION='Y';才会触发加密，且该操作会重建表（锁表 + I/O 压力） -
innodb_file_per_table=ON是前提，否则所有表共用系统表空间（ibdata1），而它不支持加密 - 密钥由
keyring_file或keyring_encrypted_file插件管理，插件没加载或路径权限不对，加密会静默失败 —— 查SHOW ENGINE INNODB STATUS的KEYRING段能发现报错
数据文件权限设置成600还不够安全
MySQL 进程以 mysql 用户运行，只要它能读，攻击者拿到该用户 shell 就能直接 cat 或 dd 出 ibd 文件。即使文件权限是 600，也挡不住进程级泄露。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 真正有效的是隔离：把数据目录（如
/var/lib/mysql）挂载在独立磁盘分区，并启用 Linux 容器（如 systemd scope）或 namespace 限制 MySQL 进程的文件系统视图 - 禁用
local_infile=OFF和secure_file_priv设为NULL，防止通过 SQL 加载外部文件间接读取磁盘 - 定期检查
ls -l /proc/$(pidof mysqld)/fd/，确认没有意外打开的非数据库文件句柄
备份文件比原库更常被拖走
很多团队花大力气加密在线表空间，却把 mysqldump 输出存成明文 .sql 放在共享目录，或用 Percona XtraBackup 备份时不加 --encrypt 参数，备份集本身就成了最肥的拖库目标。
-
mysqldump不支持内置加密，必须管道进gpg或openssl enc：mysqldump db tbl | openssl enc -aes-256-cbc -pbkdf2 -iter 100000 -salt -out backup.sql.enc - XtraBackup 的
--encrypt需配套--encrypt-key或--encrypt-key-file，且恢复时必须提供相同密钥，漏掉任意一环就无法还原 - 备份存储位置不能和 MySQL 数据目录同盘 —— 同块磁盘被攻破后，加密表空间 + 明文备份 = 白送解密线索
加密密钥丢了比没加密还麻烦
MySQL 不帮你托管密钥。用 keyring_file 插件时，密钥存在 keyring_file_data 指向的文件里；一旦这个文件损坏或覆盖，所有加密表永久不可读，ERROR 1794 (HY000) 直接报“Keyring key not found”。
- 密钥文件必须单独备份，且不能和数据库备份放一起；建议用硬件安全模块（HSM）或云厂商 KMS（如 AWS CloudHSM）替代文件型 keyring
- 测试环境务必模拟密钥丢失场景：删掉
keyring_file_data后启动 MySQL，确认能否复现错误并验证恢复流程 - 别在配置文件里硬编码密钥路径，用 systemd 的
EnvironmentFile或容器 secret 注入，避免配置误提交到代码仓库
