应用需在服务端用 AES_DECRYPT 动态解密，密钥须从环境变量或 KMS 等独立信道获取，严禁硬编码、存库或写入 SQL；MySQL 内置加密不支持跨语言互通，生产环境推荐应用层统一加解密。
用 AES_ENCRYPT 加密字段后，应用怎么安全读取？
加密数据本身不解决权限控制，它只让未授权者看不懂——但应用层必须能解密才能用。关键在：解密密钥不能硬编码、不能存在数据库、不能随 SQL 一起传。
-
AES_DECRYPT必须在应用侧调用，不是在 SQL 里做（否则密钥必然暴露在查询日志或慢查记录中） - 密钥建议从环境变量或专用密钥管理服务（如 HashiCorp Vault、AWS KMS）获取，每次请求时动态拉取，避免进程常驻内存
- MySQL 8.0+ 支持
AES_ENCRYPT(str, key)，但key参数若为字符串字面量（如'my_secret'），会被完整记录在general_log或代理层日志里 - 若必须用 SQL 解密（仅限调试或极低风险场景），至少用会话级变量传密钥：
SET @k = 'xxx'; SELECT AES_DECRYPT(data, @k) FROM t;，并确保该会话不被日志捕获
为什么不能把密钥存进数据库表或配置文件？
加密的目的是防“数据泄露后被直接利用”，如果密钥和密文在同一个数据库里，攻击者拿到备份或拖库后，解密只是多写一行 SQL 的事。
- 常见错误：建一张
config表存encrypt_key字段，再用(SELECT key FROM config WHERE id=1)当AES_ENCRYPT的第二个参数 - 更隐蔽的坑：用
LOAD_FILE('/etc/app/key.txt')读密钥——这要求 MySQL 有文件读权限，且路径对所有连接可见，等于把密钥挂到服务账户下 - 正确做法是密钥与数据物理隔离：数据库只存密文，应用启动时从独立信道加载密钥，且密钥生命周期短于数据生命周期（比如用 KMS 的临时密钥派生）
AES_ENCRYPT 的模式、填充和 IV 怎么选才不踩兼容性雷？
MySQL 默认用 ecb 模式（不推荐），而现代应用通常需要 cbc 或 gcm。但 MySQL 原生只支持 ecb 和 cbc（8.0.30+），且不暴露 IV 参数。
- MySQL
AES_ENCRYPT(str, key)实际等价于AES_ENCRYPT(str, key, 'ecb')，无 IV，无法抵抗相同明文生成相同密文的重放风险 - 若要
cbc，必须显式传第三个参数：AES_ENCRYPT(str, key, 'cbc')，且第二个参数key长度必须为 16/24/32 字节（对应 AES-128/192/256），否则报错ER_AES_INVALID_KEY_SIZE - IV 由 MySQL 内部生成并隐式附在密文前（16 字节），所以
AES_DECRYPT能自动剥离——但这也意味着你无法跨语言解密（比如 Python 用pycryptodome解不出 MySQL 加密的结果） - 生产环境若需跨系统互通，别用 MySQL 内置函数，改用应用层统一加解密（如 Go 的
crypto/aes+crypto/cipher）
权限控制真正在哪一层落地？
数据库行级权限（如 ROW LEVEL SECURITY）和加密无关；AES_ENCRYPT 是数据保护手段，不是访问控制开关。真正的权限控制必须靠应用逻辑兜底。
- 用户 A 能查到某条记录，不代表他能解密其中的
phone字段——应用得根据用户角色决定是否调用AES_DECRYPT，而不是把密文直接返回给前端 - 不要依赖视图封装
AES_DECRYPT并授予权限，因为视图定义里的密钥仍是静态字符串，可被SHOW CREATE VIEW查看 - 最易忽略的一点：加密字段的索引失效。一旦对
AES_ENCRYPT(phone, @k)建索引，查询WHERE phone = '138……'就无法走索引——权限控制若依赖模糊查询（如按手机号前缀搜索），就得另建明文辅助字段并严格隔离权限
