迁移前必须确认加密字段可逆，因MySQL无透明加密迁移能力；需确保密钥、模式、填充一致，自定义加密须复现逻辑；注意字符集用VARBINARY/BLOB；表空间加密需目标库启用对应keyring插件；密钥严禁硬编码；加密字段索引失效需用生成列等替代方案。
迁移前必须确认加密字段是否可逆
MySQL 本身不提供对已有数据的“透明加密迁移”能力，AES_ENCRYPT() 和 AES_DECRYPT() 是可逆的，但要求密钥完全一致、模式（如 ecb/cbc）和填充方式也必须匹配。如果旧库用的是自定义加解密逻辑（比如 PHP 的 openssl_encrypt() + base64_encode()），直接用 MySQL 内置函数解密会失败——常见错误是返回 NULL 或乱码。
实操建议：
- 先在测试库中抽样还原：从原库导出几条加密值，用原环境密钥和算法尝试在目标库执行
AES_DECRYPT(value, @key)，验证结果是否与原始明文一致 - 若原加密非标准 AES（例如用了哈希混淆或多次异或），必须复现相同逻辑写成 MySQL 函数或改用应用层解密再重加密
- 注意字符集：加密后是二进制数据，字段类型应为
VARBINARY或BLOB，不能存进VARCHAR（尤其 utf8mb4 下易截断或转义）
使用 MySQL 8.0+ Data Encryption at Rest 要绕开表空间限制
MySQL 原生的 innodb_encrypt_tables=ON 只加密表空间文件（.ibd），不加密传输中的数据或字段级内容。它对迁移的影响很隐蔽：如果源库启用了表空间加密，而目标库未开启或密钥不同，mysqldump 导出时不会报错，但恢复后表无法打开，错误信息类似 Tablespace is encrypted but encryption plugin is not active。
实操建议：
- 迁移前检查源库：
SELECT TABLE_SCHEMA, TABLE_NAME, CREATE_OPTIONS FROM INFORMATION_SCHEMA.TABLES WHERE CREATE_OPTIONS LIKE '%ENCRYPTION="Y"%'; - 目标库必须启用
keyring_file或keyring_okv插件，并确保keyring_file_data指向同一密钥文件（或导入等效密钥） - 不推荐跨版本迁移加密表空间：MySQL 5.7 的加密表无法被 8.0 直接识别，需先关闭加密（
ALTER TABLE ... ENCRYPTION='N'），再迁移
避免在迁移脚本里硬编码密钥
很多团队在 mysqldump --where 或迁移 SQL 中直接拼接 AES_ENCRYPT('password', 'mykey123')，这导致密钥泄露在日志、binlog、审计记录甚至运维平台历史命令中。更糟的是，一旦密钥泄漏，所有加密字段等于裸奔。
实操建议：
- 密钥绝不出现于 SQL 文本中：用 MySQL 变量临时加载，例如
SET @secret_key = UNHEX(SHA2('prod-app-key-2024', 256));，然后在 INSERT/UPDATE 中引用@secret_key - 禁止在 shell 脚本中用
-e "INSERT ... AES_ENCRYPT(..., 'xxx')"方式执行；改用预编译语句或应用层处理 - 如果必须批量加密，优先在应用代码中完成（如 Python 用
cryptography.hazmat.primitives.ciphers），再通过安全连接写入目标库
字段级加密后索引失效的替代方案
对敏感字段（如手机号、身份证号）加密后，WHERE phone = AES_ENCRYPT(?, ?) 无法走索引，查询性能断崖式下降。有人试图用固定盐值哈希做“可搜索加密”，但 MySQL 的 HASH 不抗碰撞，且无法支持范围查询或模糊匹配。
实操建议：
- 高频查询字段保留明文索引列（如
phone_hash CHAR(64) AS (SHA2(phone, 256)) STORED），加密列仅用于存储，查询走哈希列 - 合规强要求场景下，用 MySQL 8.0 的
GENERATED COLUMN+INVISIBLE列隐藏明文，对外只暴露加密列和索引列 - 绝对不要用
LIKE '%xxx%'查询加密字段——即使加了函数索引，也无法生效；这类需求必须前置到应用层解密后处理
真正难的不是怎么加，而是怎么让加密不破坏查询路径、不引入密钥管理单点故障、不把运维变成密码学考试。每一步密钥变更、算法升级、字段重构，都得同步更新应用解密逻辑和备份恢复流程——漏掉任意一环，数据就永久锁死。
