mysql 8.0.13+企业版或编译启用innodb_encrypt_tables的社区版才支持tde；需执行select * from information_schema.innodb_encryption验证，报错则无tde能力；keyring插件须active且路径权限为700；alter table encryption='y'触发copy重建并锁表；日志和binlog默认不加密。
确认 MySQL 版本与 TDE 支持是否就绪
不是所有 MySQL 8.0 都能开 TDE——必须是 8.0.13+，且二进制编译时启用了 innodb_encrypt_tables。执行 SELECT VERSION(); 和 SELECT * FROM information_schema.INNODB_ENCRYPTION;；若后者报错 Table 'information_schema.INNODB_ENCRYPTION' doesn't exist，说明当前安装包压根没带 TDE 功能，换官方社区版或企业版。
keyring_file 插件必须 ACTIVE，且路径权限严格合规
插件“存在但状态不是 ACTIVE”是最常见卡点。启动 MySQL 后立刻查：SELECT PLUGIN_NAME, PLUGIN_STATUS FROM INFORMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'component_keyring_file';（注意：MySQL 8.0 社区版用的是 component，不是旧式 plugin）
-
early-plugin-load已被弃用，改用 manifest 文件：mysqld.my必须放在mysqld可执行文件所在目录，内容为{"components": "file://component_keyring_file"} -
component_keyring_file.cnf必须放在plugin_dir目录下（查SHOW VARIABLES LIKE 'plugin_dir';），内容为{"path": "/var/lib/mysql-keyring/keyring"} -
/var/lib/mysql-keyring/目录必须由mysql用户拥有，权限设为700，不能在tmpfs、NFS或受 SELinux/AppArmor 限制的路径上 - 旧密钥文件残留会导致初始化失败：删掉
/var/lib/mysql-keyring/keyring再重启 mysqld
ALTER TABLE ENCRYPTION='Y' 实际触发全表重建，不是元数据标记
执行 ALTER TABLE t1 ENCRYPTION='Y'; 看似简单，但本质是 ALGORITHM=COPY，会锁表、重建整个表空间。它不加密老数据页——已写入磁盘的明文页仍保持原样，直到被 purge、page split 或更新覆盖。
- 必须先确保该表使用独立表空间：查
SHOW CREATE TABLE t1;，若没显式指定TABLESPACE，先执行ALTER TABLE t1 TABLESPACE=innodb_file_per_table; - 磁盘需预留 ≥1.5 倍表大小空间，否则报错
ERROR 1767 (HY000): Failed to initialize tablespace - 值只能是
'Y'或'N'，用ON、1、TRUE全部报错 - 验证是否生效：查
SELECT NAME, ENCRYPTION_TYPE FROM INFORMATION_SCHEMA.INNODB_TABLESPACES WHERE NAME LIKE '%t1%';，返回AES表示已加密
日志和 binlog 默认不加密，TDE 覆盖面极窄
TDE 只管 InnoDB 数据页（.ibd 文件），ib_logfile*、binlog、undo log、临时表、查询缓存全都不加密。迁移后若真要满足等保或金融密评，必须额外配：
-
innodb_redo_log_encrypt=ON（MySQL 8.0.17+） -
binlog_encryption=ON（同上版本），但会破坏与旧从库的兼容性 - 这两项开启后显著增加 CPU 开销，且无法回退到不支持加密的 MySQL 版本
真正容易被忽略的是：密钥文件一旦泄露，攻击者可用 component_keyring_file.so 反解出所有表空间密钥——这不是理论风险，而是 keyring_file 的设计事实。生产环境别只盯着 ENCRYPTION='Y'，得先想清楚密钥怎么管。
