MySQL TDE仅对新写入或重建的数据页加密，社区版不支持，必须用企业版8.0.13+；需满足innodb_file_per_table=ON、InnoDB引擎、正确配置keyring_file.so，否则.ibd仍明文落盘。
MySQL 的 TDE 不是“配完重启就自动加密所有数据”的功能，它只对满足条件的新写入或重建后的数据页生效；社区版完全不支持，必须用企业版 8.0.13+，且漏掉任何一个前提（比如 innodb_file_per_table=OFF 或 keyring_file.so 权限不对），.ibd 文件照样以明文落盘。
确认 MySQL 版本与存储引擎是否满足 TDE 基础条件
TDE 是企业版专属能力，社区版无论 5.7 还是 8.0 都没有 innodb_encrypt_tables、innodb_encrypt_log 等系统变量，配置了也会被忽略或导致启动失败：
- 必须使用 MySQL 企业版 8.0.13 或更高版本（查版本：
SELECT VERSION();，再核对官网发行说明） -
innodb_file_per_table必须为ON—— 共享表空间ibdata1无法被单独加密，加密只作用于独立.ibd文件 - 表引擎只能是 InnoDB；
MEMORY、CSV、临时表等不支持加密 - 已存在的未加密
.ibd文件不会自动重写加密，必须显式重建
keyring_file.so 插件配置的三个致命错误点
keyring_file.so 是最常用但最容易配崩的密钥后端，MySQL 启动时会严格校验路径、权限和初始化状态：
-
early-plugin-load=keyring_file.so必须放在[mysqld]段最顶部，且不能带路径（如early-plugin-load=/usr/lib/mysql/plugin/keyring_file.so会直接报错退出） -
keyring_file_data指向的文件路径，其所在目录需由mysql用户完全拥有，且目录权限不能是777或775；典型错误报错：Plugin 'keyring_file' init function returned error - 该密钥文件应不存在——MySQL 启动时会自行创建并初始化；若手动
touch出来再chown，MySQL 可能因检测到非空文件而拒绝加载密钥环
让 .ibd 文件真正加密的两种触发方式
配置完插件和参数后，TDE 不会扫描现有表，必须人工干预才能让 .ibd 进入加密状态：
- 新建表时直接声明：
CREATE TABLE t1 (id INT) ENCRYPTION='Y';—— 此时.ibd创建即加密，密钥存于表空间头部，受主密钥保护 - 对已有表启用加密：
ALTER TABLE t1 ENCRYPTION='Y';—— 触发全表重建（类似OPTIMIZE TABLE），期间锁表、消耗 I/O；注意：旧.ibd文件在删除前仍可被直接读取，操作窗口需确保物理安全 - 设全局默认：
SET PERSIST innodb_encrypt_tables=ON;（需SUPER权限），此后新建的 InnoDB 表默认加密，但已有表不受影响，也不覆盖CREATE TABLE ... ENCRYPTION='N'的显式声明
验证加密是否真实生效的硬性检查项
别只信日志里 “keyring loaded” 这种提示，关键看磁盘文件本身是否加密：
- 用
hexdump -C table_name.ibd | head -20查看文件头 —— 加密后的.ibd开头不再是可读的len: 16或INCOMPATIBLE字符串，而是杂乱二进制；明文则清晰可见表结构标识 - 跨实例导入测试：把加密表的
.ibd和.cfg拷到另一个未启用 TDE 的 MySQL 实例，执行ALTER TABLE ... IMPORT TABLESPACE—— 应报错Tablespace is encrypted，否则说明没真加密 - 检查表元数据：
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE CREATE_OPTIONS LIKE '%ENCRYPTION%';，结果为ENCRYPTION='Y'仅表示 DDL 层声明，不等于磁盘已加密
最常被跳过的环节是：没验证文件头、没做跨实例导入测试、以为开了 innodb_encrypt_tables 就万事大吉。TDE 的“透明”只体现在应用层，对 DBA 来说，每一步都得亲手确认字节级效果——毕竟硬盘丢了，靠的是 .ibd 文件本身能不能扛住十六进制编辑器的直读。
