MySQL中AES_ENCRYPT返回VARBINARY导致查询乱码，需用AES_DECRYPT配对解密；密钥长度须严格匹配（如AES-256需32字节），生产环境必须显式指定加密模式（如'aes-256-gcm'），避免使用不安全的默认ECB模式。
MySQL 用 AES_ENCRYPT 存敏感字段，但查出来是乱码？
不是加密失败，是解密时没配对使用 AES_DECRYPT，而且默认返回 VARBINARY，直接 SELECT 会显示十六进制或乱码。
- 必须用
AES_DECRYPT+ 同一把密钥 + 同样的模式（如AEAD_AES_256_GCM）才能还原；AES_ENCRYPT返回的是二进制，别用CAST(... AS CHAR)硬转，可能截断或乱码 - 密钥长度要严格匹配：AES-128 要 16 字节，AES-192 是 24，AES-256 是 32 —— 用
UNHEX(SHA2('mykey', 256))这类方式生成更稳，别手拼字符串 - MySQL 5.7+ 默认用 ECB 模式（不安全），生产务必显式指定
MODE参数，比如AES_ENCRYPT(data, key, 'aes-256-gcm')，否则审计过不了
PostgreSQL 的 pgcrypto 加密后，应用层解不开？
常见原因是加解密使用的盐值、IV 或填充方式不一致。PostgreSQL 默认的 crypt() 是单向哈希，不能“解密”——真要可逆，得用 pgp_sym_encrypt() 配合 pgp_sym_decrypt()。
-
pgp_sym_encrypt()默认用 AES-128-CFB + 自动管理 IV 和 salt，解密时只要密钥对就行；但若手动传入iv参数，两边必须完全一致，否则返回NULL - 密钥建议用
gen_random_bytes(32)生成，别用明文密码直接当密钥；如果用passphrase，记得加pgp_sym_encrypt(data, passphrase, 'cipher-algo=aes256')显式指定算法 - 字段类型必须是
BYTEA，别建为TEXT—— 插入时 PostgreSQL 会自动 hex-encode，取出来再解密前要先DECODE(..., 'hex')，否则报错invalid byte sequence
应用连接数据库时被拒绝访问加密字段，权限配置漏了哪步？
加密本身不改变权限模型，但实际中常因绕过视图/函数封装，或误用 DEFINER 权限导致执行失败。
- 如果把解密逻辑写在存储函数里（比如
decrypt_ssn(v BYTEA)），函数要用SECURITY DEFINER，且定义者账号必须有EXECUTE权限，调用者账号则只需EXECUTE，不用给底层表SELECT - 别让应用直连加密列；更稳妥的是建只读视图，字段用
AES_DECRYPT包一层，并限制该视图只对特定角色GRANT SELECT - 注意 MySQL 的
SQL_MODE=STRICT_TRANS_TABLES下，AES_DECRYPT解密失败会返回NULL而非报错，容易掩盖密钥不匹配问题；加个IS NULL判断日志才看得见
Java 应用读取加密字段时抛 SQLDataException: Data type mismatch
这是 JDBC 驱动尝试把 VARBINARY 当字符串映射到 String 类型，底层字节流和字符编码对不上。
- Java 侧读取时，用
ResultSet.getBytes("ssn_encrypted")拿byte[]，别用getString()；解密后再转new String(decryptedBytes, StandardCharsets.UTF_8) - MyBatis 中如果用了
resultType="map"，它会自动调getString，此时要么改用resultMap指定jdbcType=BINARY，要么在@SelectSQL 里套一层HEX(ssn_encrypted)返回字符串再 hex-decode - Spring Data JPA 更麻烦：自定义
@Converter时，convertToDatabaseColumn必须返回byte[]，且实体字段类型也得是byte[]，别用String或ByteBuffer，否则 Hibernate 会默默转码
