SQL Server TDE启用失败主因是密钥链缺失（SMK→DMK→DEK），需依次创建服务主密钥、数据库主密钥、证书及数据库加密密钥；MySQL加密慢因异步线程未启用或轮换参数不当；PostgreSQL pgcrypto仅为行级加密，防磁盘泄露须用LUKS等OS层方案；TDE备份恢复失败多因证书及私钥导出不全。
SQL Server 透明数据加密（TDE）启用失败：常见报错 Msg 33101 怎么解
直接原因通常是数据库主密钥（DMK）没创建，或服务主密钥（SMK）未被正确解密。TDE 不是开关一按就生效，它依赖完整的密钥链：SMK → DMK → 数据库加密密钥（DEK）。缺任意一环，ALTER DATABASE ... SET ENCRYPTION ON 就会抛 Msg 33101。
实操建议：
- 先确认 SMK 是否存在：
SELECT * FROM sys.symmetric_keys WHERE name = '##MS_ServiceMasterKey##' - 若无 DMK，必须在目标数据库上下文中创建：
CREATE MASTER KEY ENCRYPTION BY PASSWORD = 'StrongPass!2024'（注意：密码别丢，且不能用弱口令） - 再创建证书（TDE 推荐用证书而非非对称密钥）：
CREATE CERTIFICATE TDECert WITH SUBJECT = 'TDE Certificate for MyDB' - 最后绑定 DEK 并开启：
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256 ENCRYPTION BY SERVER CERTIFICATE TDECert，再执行加密命令
MySQL 启用 InnoDB 表空间加密后查询变慢？不是加密本身的问题
MySQL 的 innodb_encrypt_tables=ON 确实会带来少量 CPU 开销，但真正拖慢查询的往往是配套配置没调好。比如默认的 innodb_encryption_threads=0 表示禁用异步加解密线程，所有 I/O 加密都挤在主线程里做；又或者 innodb_encryption_rotation_iops 设得太低，导致密钥轮换时卡住写入。
实操建议：
- 务必启用异步线程：
SET GLOBAL innodb_encryption_threads = 4（根据 CPU 核数调整） - 密钥轮换期间避免大事务：
innodb_encryption_rotate_key_age默认 1，意味着每 1 天自动轮换，生产环境建议设为 30 或更高 - 加密只对静态数据有效 —— 内存中、网络传输中的数据仍明文，别误以为开了就“全链路安全”
- 备份文件（如
mysqldump输出）不自动加密，需额外用gpg或openssl处理
PostgreSQL 的 pgcrypto 不等于磁盘级加密，别混淆使用场景
pgcrypto 是函数扩展，提供 encrypt()、decrypt() 这类行级加解密能力，但它不加密数据文件本身。用户常误以为启用了 pgcrypto 就能防磁盘被盗，其实 .base 目录下的数据文件仍是明文 —— 攻击者拿走整个 PGDATA 目录就能直接读表。
实操建议：
- 真要防磁盘泄露，得靠 OS 层：Linux 下用 LUKS（
cryptsetup），或 ZFS 原生加密（zfs set encryption=on） -
pgcrypto适合字段级敏感数据（如身份证号），但必须自己管理密钥生命周期，且索引失效、无法用 WHERE 加速查询 - 别在应用层用
pgcrypto做密码哈希 —— 密码该用pg_authid.rolpassword或crypt()+ salt，不是encrypt()
TDE 加密后备份恢复失败？检查证书和私钥导出是否完整
TDE 加密的数据库备份，恢复到另一台服务器时必然失败，除非目标实例有完全相同的证书及其私钥。很多人只导出了证书（BACKUP CERTIFICATE ... TO FILE），却忘了导出私钥（WITH PRIVATE KEY 子句），结果恢复时报 Cannot find server certificate 或更隐蔽的 Decryption failed。
实操建议：
- 导出证书必须带私钥：
BACKUP CERTIFICATE TDECert TO FILE = 'TDECert.cer' WITH PRIVATE KEY (FILE = 'TDECert.pvk', ENCRYPTION BY PASSWORD = 'PvkPass!') - 目标服务器导入时顺序不能错：先建 master key（如果还没），再
CREATE CERTIFICATE ... FROM FILE，再用WITH PRIVATE KEY指定 .pvk 和密码 - 证书名、数据库名、密钥密码三者任何一处拼写错误，都会导致恢复静默失败（日志里只有“encryption key not found”这种模糊提示）
密钥管理比加密本身更耗神 —— 证书过期、私钥丢失、密码遗忘，任一环节断掉，整个数据库就不可恢复。别把密钥文件随手放 Git 或共享目录里。
