TDE与PHP应用层加密本质不同：TDE在数据库存储层自动加解密，对应用透明，防物理窃取；openssl_encrypt在应用层手动加密字段，存入数据库即为密文，防DBA越权查看，二者属分层防御的上下两层。
openssl_encrypt 和 openssl_decrypt 是 PHP 应用层加密的主力函数，但它们和数据库 TDE（Transparent Data Encryption）完全不是一回事——别混用，也别指望靠它们“替代”TDE。
TDE 是数据库自己在写盘/读盘时自动加解密，对应用零感知；而 PHP 加密是数据进数据库前就变成密文，数据库里存的永远是乱码。两者目标一致（防磁盘窃取），但作用层、风险面、运维成本截然不同。
什么时候该用 openssl_encrypt 而不是 TDE
当你需要保护的是个别字段（比如身份证号、银行卡号），且这些字段不能被 DBA 或运维人员直接查到明文时，必须用应用层加密。
- TDE 无法阻止已登录数据库的合法用户执行
SELECT id_card FROM users—— 因为它只加密磁盘文件，内存和 SQL 结果都是明文 -
openssl_encrypt加密后的值是纯字符串，数据库不理解其语义，即使 DBA 有最高权限，看到的也只是 Base64 编码的密文 - 你得自己处理 IV 生成、拼接、分隔、Base64 编码等细节，漏一步就解密失败
- 密钥不能写死：
$_ENV['AES_KEY']或 KMS 接口获取是底线，硬编码'my-secret-key-256bit'属于高危行为 - 加密后字段类型建议用
TEXT或足够长的VARCHAR（AES-256-CBC + IV + Base64 后长度约比原文多 40%）
MySQL 8.0 开启 TDE 的真实门槛
TDE 不是点个开关就能用的功能，它依赖底层基础设施和权限链路，缺一不可。
立即学习“PHP免费学习笔记（深入）”；
- 实例必须是高可用或集群版，基础版不支持
- 内核小版本 ≥ 20191015 —— 很多老实例卡在 2018xxxx，升级前先确认兼容性
- 必须提前开通阿里云 KMS，并完成 RDS 对 KMS 的服务角色授权（不是简单“勾选”，要进 RAM 控制台配策略）
- 开通过程会重启实例，约 15 秒不可用；如果应用没配连接池重试或自动重连，就会报
MySQL server has gone away - 一旦开通，
innodb_encrypt_algorithm参数就锁死了，默认是AES_256_CBC，想切 SM4？得提工单，且有解析失败风险
ALTER TABLE ... ENCRYPTION='Y' 这条命令到底动了什么
这条语句不会立刻加密整张表，而是标记该表为“待加密”，真正加密发生在后续的 DML 或后台刷脏页过程中。
- 执行后，新插入/更新的数据页会按 TDE 规则加密写入；已有数据页是否加密，取决于是否被重新刷入磁盘（例如执行
OPTIMIZE TABLE） - 加密只作用于 InnoDB 表空间（.ibd 文件），系统表空间（ibdata1）、日志文件（redo log）是否加密，由全局参数
innodb_encrypt_tables和innodb_encrypt_log控制 - 注意：
ENCRYPTION='Y'不影响查询性能本身，但 CPU 解密开销会上升 —— 监控show global status like 'Innodb_buffer_pool_read_requests'和CPU%要同步看 - 解密表用
ALTER TABLE t ENCRYPTION='N'，但不会自动把已加密的数据页还原，只是停止新加密；已加密页仍保持密文，直到被覆盖或重建
最常被忽略的密钥生命周期问题
TDE 密钥由 KMS 托管，但“托管”不等于“无忧”。KMS 密钥被禁用、计划删除、或权限策略变更，都会导致整个数据库实例无法启动。
- RDS 实例重启时会尝试调用 KMS 解密主密钥，若 KMS 返回
AccessDenied或NotFound，实例将卡在“启动中”状态 - 自定义密钥（BYOK）需确保 KMS 密钥状态为
Enabled，且服务角色拥有kms:Decrypt权限 - 不要依赖“阿里云自动生成密钥”的长期可用性 —— 它可能随账号注销或资源清理被回收
- TDE 开通后无法关闭，也无法更换密钥；若真要换，只能导出明文 → 新实例开启 TDE → 导入，中间存在窗口期
TDE 和 PHP 应用加密不是二选一，而是分层防御里的上下两层：TDE 防物理窃取，PHP 加密防逻辑越权。真正难的从来不是怎么写那行 openssl_encrypt，而是密钥谁管、轮多久、失效了谁兜底。
