不能用 UPDATE ... SET field = AES_ENCRYPT(...) 一键加密，因返回二进制数据易导致截断乱码，且无IV致相同明文加密结果固定，存在统计分析风险。
直接批量加密已有数据库字段不安全，也不推荐——必须先备份、再逐行解密-重加密、最后验证一致性。
为什么不能用 UPDATE ... SET field = AES_ENCRYPT(...) 一键加密？
MySQL 的 AES_ENCRYPT() 返回二进制数据（BLOB 类型），若原字段是 VARCHAR，直接写入会导致截断、乱码或隐式转换失败；更关键的是，它不携带 IV（初始化向量），无法保证相同明文每次加密结果不同，存在统计分析风险。
实际中容易踩的坑：
- 字段类型没提前改成
VARBINARY或BLOB，加密后查出来是空或乱码 - 没设统一密钥和 IV 存储策略，后续 PHP 解密时对不上
- 一次性全表更新卡死、锁表时间过长，线上服务中断
- 没校验加密前后长度变化，导致
INSERT报Data too long
PHP 中用 openssl_encrypt() 安全循环加密敏感字段
核心原则：每条记录独立加解密，显式管理 IV，密文存为 Base64 字符串（兼容 VARCHAR 字段）。
立即学习“PHP免费学习笔记（深入）”；
实操要点：
- 加密前确认目标字段类型已改为
VARCHAR(255)或更大（Base64 后长度 ≈ 原始长度 × 1.33 + 开销） - 使用
openssl_encrypt($data, 'aes-256-cbc', $key, 0, $iv)，其中$iv必须随机生成且随密文一起存储（例如拼在密文前，或另存一列） - 务必用
password_hash()衍生密钥，别硬编码字符串；IV 用random_bytes(16)生成 - 循环中加
try/catch，失败时记录$id和错误信息，避免中断整个流程
示例片段：
$key = hash_pbkdf2('sha256', $masterSecret, $salt, 100000, 32);
$iv = random_bytes(16);
$ciphertext = openssl_encrypt($plain, 'aes-256-cbc', $key, 0, $iv);
$stored = base64_encode($iv . $ciphertext); // IV 和密文一起存
如何安全迁移旧数据？分三步走
不要跳过任何一步，尤其不能省略“验证”环节。
-
第一步：只读导出 —— 用
SELECT id, email, phone FROM users WHERE ... LIMIT 1000分批拉取，避免内存溢出 -
第二步：逐条加密+写回 —— 更新时用
WHERE id = ?精确匹配，防止错改；建议加updated_at时间戳辅助追踪进度 -
第三步：抽样解密比对 —— 随机选 5% 加密后的记录，用
openssl_decrypt()还原，确认与原始明文一致
注意：如果表有主从复制，写操作要避开高峰期；若字段被索引，加密后该索引失效，搜索需改用应用层解密后匹配（或引入加密索引方案，那是另一回事）。
加密后查询和业务逻辑怎么适配？
PHP 层所有读取该字段的地方，必须插入解密逻辑；不能再用 SELECT * 直接吐给前端。
- 封装一个
decryptField($encrypted, $key)工具函数，统一处理 IV 提取和openssl_decrypt() - ORM 模型中重写
getPhoneAttribute()等访问器，在获取时自动解密 - 搜索敏感字段（如“查某手机号用户”）只能靠解密后模糊匹配，性能差——此时应考虑加非敏感标识字段（如脱敏号段）辅助查询
- 日志、缓存、导出 CSV 等环节，必须检查是否意外打印/落盘了明文
最容易被忽略的一点：加密不是访问控制。即使字段加密了，数据库账号权限、SQL 注入漏洞、日志泄露依然能让攻击者拿到密文+密钥——加密只是纵深防御里的一环，不是银弹。
