mysql tde需企业版8.0.13+、innodb_file_per_table=on且显式启用encryption，配置错误或版本不符将导致.ibd明文落盘；keyring_file.so配置须严格遵循路径、权限及初始化规范，加密生效须通过文件头验证与跨实例导入测试。
MySQL物理文件加密（TDE）能有效防硬盘丢失泄密，但前提是配置正确、密钥隔离、且仅作用于实际写入磁盘的数据页。社区版不支持，必须用 MySQL 企业版 8.0+；哪怕只漏配一个关键项，.ibd 文件仍可能以明文落地。
确认 MySQL 版本与引擎是否满足 TDE 基础条件
TDE 不是“开了就生效”的开关，它依赖底层能力：
- MySQL 必须是 企业版 8.0.13 或更高版本 —— 社区版无论 5.7 还是 8.0 都不提供
innodb_encrypt_tables、innodb_encrypt_log等系统变量，强行配置会启动失败或静默忽略 - InnoDB 表必须启用
innodb_file_per_table=ON，否则共享表空间ibdata1无法被单独加密 - 表不能是临时表、内存表（
MEMORY）、CSV 引擎等非 InnoDB 类型 - 加密仅作用于新写入或重建后的数据页，已存在的未加密
.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 —— MySQL 启动时会拒绝加载权限过宽的 keyring 文件，典型报错：Plugin 'keyring_file' init function returned error - 该文件首次启动时自动生成，但若手动 touch 出来再 chown，MySQL 可能因文件非空而拒绝初始化密钥环；应确保路径存在、权限正确、文件不存在，让 MySQL 自行创建
让 .ibd 文件真正加密的两种操作方式
配置完插件和参数后，加密不会自动覆盖所有表，必须显式触发：
- 新建表时直接声明：
CREATETABLEt1(idINT)ENCRYPTION='Y';—— 此时.ibd创建即加密，密钥由主密钥保护后存入表空间头部 - 对已有表启用加密：
ALTERTABLEt1ENCRYPTION='Y';—— 这会触发全表重建（类似 OPTIMIZE），期间锁表、消耗 I/O，且旧.ibd文件删除前仍可被读取，需确保操作窗口安全 - 若只想默认加密所有新表，可设全局变量：
SETPERSISTinnodb_encrypt_tables=ON;（需 SUPER 权限），但注意：该设置不影响已存在表，也不影响CREATE TABLE ... ENCRYPTION='N'的显式关闭行为
验证加密是否真实生效的关键检查项
别只信 SHOW PLUGINS，要验证到文件层：
- 查表状态：
SELECT TABLE_NAME, ENCRYPTION FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='your_db' AND TABLE_NAME='t1';—— 返回ENCRYPTION='Y'仅表示元数据标记，不代表物理加密完成 - 看文件内容：用
hexdump -C t1.ibd | head -20查看前几十字节，加密后开头不再是标准 InnoDB page header（如00 00 00 00 ff ff ff ff），而是随机字节；但注意：前几个页（如 FSP_HDR）可能仍为明文，这是正常设计 - 最关键一步：停库 → 复制
t1.ibd到另一台未配置 TDE 的 MySQL 实例 → 尝试ALTER TABLE t1 IMPORT TABLESPACE;—— 若报错Tablespace is encrypted或直接崩溃，说明加密真实有效
真正容易被忽略的是密钥生命周期管理：keyring_file.so 把主密钥明文存本地文件，一旦该文件被备份、同步或误删，整个加密体系即失效；生产环境必须换成 keyring_okv 或对接 HSM，且密钥轮换后需重新加密表空间密钥（不是重刷全部数据），否则旧密钥泄露风险仍在。
