mysql社区版8.0.13+开启tde需同时满足：版本≥8.0、innodb独立表空间启用、keyring_file插件active；缺一则alter table ... encryption='y'失败。
MySQL 社区版 8.0.13+ 可以开启 TDE，但必须满足三个硬性前提：版本支持、InnoDB 独立表空间、keyring_file 插件正确加载；缺一不可，否则 ALTER TABLE ... ENCRYPTION='Y' 会静默失败或报错。
确认 MySQL 是否真支持 TDE
别只看版本号。执行 SELECT * FROM information_schema.INNODB_ENCRYPTION; —— 如果报错 Table 'information_schema.INNODB_ENCRYPTION' doesn't exist，说明编译时没启用 innodb_encrypt_tables，哪怕你是 8.0.33 也没用。社区版还依赖发行版是否打包了加密模块（如 Ubuntu 官方 APT 包通常不带，需自行编译或换 Percona Server）。
检查方式还包括：
- 运行
SHOW VARIABLES LIKE 'have_innodb%';，确认have_innodb_encryption值为YES - 查
SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'keyring_file';，状态必须是ACTIVE
keyring_file 插件加载顺序和权限陷阱
early-plugin-load=keyring_file.so 必须写在 [mysqld] 段最开头，且必须在任何 plugin_load_add 或其他插件配置之前。顺序错，MySQL 启动时不会报错，但后续所有加密操作都会被忽略。
密钥文件路径（如 keyring_file_data=/var/lib/mysql-keyring/keyring）有严格权限要求：
- 目录必须由
mysql用户拥有，且group和other不能有写权限（即chmod 750或更严） - 文件本身不能存在，首次启动时 MySQL 会自动创建；若旧环境残留
keyring文件（尤其曾用过keyring_encrypted_file），格式不兼容，必须手动删掉再重启 - SELinux 或 AppArmor 启用时，需额外放行该路径读写，否则 MySQL 日志里只有模糊的 “Cannot open keyring file”
对已有表开启加密的实际步骤
TDE 加密不是“开关式”，而是重建表空间的过程，会锁表、触发全量 I/O，生产环境务必评估窗口期。
操作前先确认表是否满足前提：
- 引擎必须是
InnoDB：SHOW CREATE TABLE t1;中含ENGINE=InnoDB - 必须使用独立表空间：
SHOW VARIABLES LIKE 'innodb_file_per_table';返回ON，且建表语句不含TABLESPACE = innodb_system - 若当前在系统表空间（
ibdata1），需先执行ALTER TABLE t1 TABLESPACE = innodb_file_per_table;（这步本身也锁表）
真正加密命令只有一行，但注意细节：
-
ALTER TABLE t1 ENCRYPTION='Y';—— 单引号不能省，值只能是'Y'或'N'，ON/TRUE/1全部报错 - 执行后不会立即完成，后台异步扫描并重写数据页；可通过
SELECT NAME, ENCRYPTION_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE '%t1%';查看是否返回AES - 加密过程无法中断，中断会导致表损坏，只能从备份恢复
云数据库（RDS/TDSQL）和本地部署的关键区别
云厂商（腾讯云、阿里云等）的 TDE 是实例级开关，控制台一键开通，底层由 KMS 托管密钥，你不需要、也不允许碰 keyring_file 配置。但代价是：开通后无法关闭、无法更换密钥、备份恢复到本地前必须解密。
本地自建 MySQL 开启 TDE 后，密钥完全由你掌控，但也意味着密钥丢失 = 数据永久不可读。KMS 不是可选项，是强依赖——没有它，云上实例根本无法启用 TDE；而本地部署若不用 KMS，则必须自己轮换、备份、审计 keyring 文件，稍有疏忽就踩进运维黑洞。
