sql本身不提供安全的敏感字段加密存储能力，子查询无法绕过该限制；加密必须在应用层完成，数据库仅适合做确定性加密后的等值比对，且需严格匹配密钥、iv、字符集与字段类型，否则将导致索引失效、密钥泄露或比对失败。
SQL本身不提供安全的敏感字段加密存储能力，子查询无法绕过这个根本限制——加密必须在应用层完成，数据库只适合做确定性加密后的比对（如使用 AES_ENCRYPT / AES_DECRYPT），且仅限于MySQL等少数引擎；直接在SQL中嵌套加密函数做WHERE条件比对，会破坏索引、暴露密钥、产生不可逆的乱码风险。
为什么不能靠子查询“自动加密再比对”
子查询只是执行顺序上的嵌套逻辑，它不改变函数执行位置或安全性模型。常见误用是写类似 SELECT * FROM users WHERE password = (SELECT AES_ENCRYPT('123456', @key))，这会导致：
-
AES_ENCRYPT在每次查询时动态执行，无法利用索引，全表扫描成常态 - 密钥
@key若硬编码在SQL里，会被慢查询日志、审计日志、代理层明文捕获 - 不同MySQL版本对
AES_ENCRYPT的默认模式（如 ECB vs CBC）和填充行为不一致，跨库迁移极易比对失败 - 子查询返回的是二进制 blob，若字段类型为
VARCHAR，隐式转换会截断或报错Truncated incorrect DOUBLE value
MySQL中唯一可行的确定性比对方案
前提是：加密已在应用层完成，且使用固定IV（或无IV的ECB，仅测试环境）、统一字符集、显式类型转换。数据库只负责存储密文并做等值比对：
- 存储时，应用层调用
AES_ENCRYPT('plain', @key)得到BLOB，插入前确保目标字段为VARBINARY(255)（不是VARCHAR） - 比对时，WHERE 条件必须用相同密钥重算一次：
WHERE encrypted_ssn = AES_ENCRYPT(?, @key)，? 是应用传入的明文 - 若想避免每次传密钥，可将密钥哈希后拼接为列名前缀（如
ssn_v1_3a7f），但密钥仍不可存于SQL - 注意：MySQL 8.0+ 默认禁用
AES_ENCRYPT的 ECB 模式，需显式指定AES_ENCRYPT(?, @key, 'aes-128-ecb')，否则报错Function or expression 'AES_ENCRYPT' cannot be used in this context
PostgreSQL 或 SQL Server 怎么办
它们没有内置的、开箱即用的对称加密函数支持比对场景：
- PostgreSQL 需依赖
pgcrypto扩展，且encrypt()返回 bytea，WHERE 中必须用decrypt()反向解密比对——这等于把密钥和明文同时送进数据库，完全丧失加密意义 - SQL Server 的
ENCRYPTBYPASSPHRASE要求密钥作为参数传入，同样无法索引，且密文长度随明文变化，LIKE或=均不可靠 - 真正可用的是 TDE（透明数据加密）或 Always Encrypted，但那是列级加密，由驱动层解密，SQL语句里永远见不到明文——子查询在这里毫无作用空间
加密不是SQL函数能兜底的事。子查询嵌套再深，也变不出密钥管理、IV生成、字符编码对齐这些应用层职责。最容易被忽略的一点：哪怕所有函数调用都正确，只要密文字段没设成 VARBINARY 或没关掉 MySQL 的 sql_mode=STRICT_TRANS_TABLES，一次隐式转换就让整条记录比对失效。
