启用 mysql tde 需先加载 keyring_file 插件并配置 keyring_file_data 路径，重启 mysqld 后验证插件状态为 active；alter table encryption=’y’ 会重建表且不自动重写旧数据；keyring_file 不满足密钥分离等合规要求，推荐使用 keyring_okv 或云 kms 方案。
怎么启用 MySQL TDE（以社区版 keyring_file 为例）
MySQL 8.0+ 才支持原生 TDE，低于这个版本直接放弃；启用不是执行一条 SQL 就完事，必须先让密钥环插件跑起来，否则 CREATE ENCRYPTION KEY 会报错 Error 3182 (HY000): Cannot create key without keyring plugin enabled。
- 在
my.cnf的[mysqld]段落里加两行：early-plugin-load=keyring_file.so和keyring_file_data=/var/lib/mysql-keyring/keyring -
/var/lib/mysql-keyring/目录必须由mysql用户可读写，且不能放在 tmpfs 或 NFS 上（keyring_file 不支持） - 修改后必须重启 mysqld，
service mysql restart，热加载不生效 - 启动后检查：
select PLUGIN_NAME, PLUGIN_STATUS FROM INforMATION_SCHEMA.PLUGINS WHERE PLUGIN_NAME = 'keyring_file';—— 状态必须是ACTIVE
加密表空间时为什么 ALTER TABLE 没反应？
ALTER TABLE t1 ENCRYPTION='Y' 看似简单，但实际触发的是重建表（ALGORITHM=copy），不是元数据标记。这意味着：
- 表越大，锁表时间越长，期间 DML 阻塞
- 如果磁盘剩余空间不足 1.5 倍表大小，操作会失败并回滚，错误类似
ERROR 1767 (HY000): Failed to initialize tablespace for <code>db.t1 - 加密只作用于新写入的数据页，已存在的未加密页不会自动重写——也就是说，老数据仍以明文躺在磁盘上，直到被 purge 或 page split 覆盖
- 日志（redo / binlog）默认不加密，需额外配置
innodb_redo_log_encrypt=ON和binlog_encryption=ON（MySQL 8.0.17+）
keyring_file 安全吗？为什么企业都绕开它
keyring_file 把主密钥以明文形式（AES 加密过，但密钥材料仍在本地文件）存硬盘，本质是“把钥匙挂门把手上”。它满足不了等保三级、GDPR、金融行业密评中关于“密钥分离”和“集中管控”的基本要求。
- 密钥文件一旦被拖库，攻击者可用
keyring_file.so插件反解出所有表空间密钥 - 无法审计谁在什么时候调用了哪个密钥
- 不支持密钥轮换后自动重加密存量数据（
ALTER TABLE ... ENCRYPTION='Y'是手动逐个执行的） - 替代方案：用
keyring_okv（对接 oracle Key Vault）、keyring_aws（对接 AWS KMS）或云厂商托管方案（如腾讯云 TDSQL 的 KMS 集成），这些才是合规场景下的真实选择
TDE 对性能的影响到底多大？
TDE 加解密发生在 InnoDB buffer pool 和磁盘 I/O 之间，所以影响集中在 CPU 和 I/O 路径：
- 典型负载下，CPU 使用率上升约 3%～7%，高并发小事务场景更明显
- 随机读写密集型业务（比如订单详情查询）延迟增加约 5%～10%，顺序扫描影响较小
-
tempdb会自动继承加密状态（只要有任何用户表启用了 TDE），但系统表空间（ibdata1）不支持加密 - 最容易被忽略的一点：备份工具如
mysqldump产出的是明文 SQL，不等于加密——你仍需用mysqlpump --encrypt或物理备份 + KMS 加密通道，否则备份文件本身成了最大泄露面
密钥管理永远比加密动作本身更难，而 TDE 的“透明”只对应用层成立，对 dba 来说，每一步都得亲手校验路径、权限、算法、备份链路——漏掉任意一环，加密就只剩心理安慰。