ENCRYPTBYKEY 返回 NULL 的根本原因是密钥未显式打开，且必须在当前会话中执行 OPEN SYMMETRIC KEY；其返回值为 VARBINARY，须存入 VARBINARY(8000) 字段并避免隐式转换；DECRYPTBYKEY 还需确保用户具备证书 VIEW DEFINITION 和密钥 REFERENCES 权限，且解密后需显式转为字符串。
ENCRYPTBYKEY 必须显式打开密钥才能工作，否则返回 NULL；直接在存储过程中调用却没效果，八成是漏了这步。
为什么 ENCRYPTBYKEY 总是返回 NULL
不是函数坏了，是密钥根本没处于“已打开”状态。SQL Server 不会自动加载对称密钥——哪怕它已存在、已加密、甚至刚被创建完。
- 每次调用
ENCRYPTBYKEY前，必须执行OPEN SYMMETRIC KEY your_key_name DECRYPTION BY CERTIFICATE your_cert_name - 建议加前置检查：
IF NOT EXISTS (SELECT * FROM sys.openkeys WHERE key_name = 'your_key_name')，避免重复打开报错 - 密钥打开后只在当前会话有效；若存储过程里有
ROLLBACK、RETURN提前退出、或长事务等待，密钥可能已被隐式关闭
ENCRYPTBYKEY 的字段类型和转换陷阱
它返回的是二进制数据，不是字符串。往 NVARCHAR 或 VARCHAR 字段里插，SQL Server 会静默转码，解密时直接失败。
- 目标列类型必须是
VARBINARY(8000)（AES_256 加密后膨胀约 100 字节，8000足够覆盖） - 插入前显式转码：
CONVERT(VARBINARY(8000), @plain_text)，别依赖隐式转换 - 明文长度不能超约
7900字节（受 AES 填充和头部开销限制），超长内容需截断或分块处理
DECRYPTBYKEY 解密失败的常见权限与上下文问题
能加密不等于能解密。即使密钥打开了，DECRYPTBYKEY 还是返回 NULL，大概率卡在权限或上下文上。
- 执行用户必须对证书有
VIEW DEFINITION权限，对对称密钥有REFERENCES权限 - 如果存储过程用了
EXECUTE AS OWNER，owner 用户也得有这两项权限（权限不继承） - 解密结果是
VARBINARY，必须再用CONVERT(NVARCHAR, ...)转成文本，漏这步前端看到的就是乱码字节 - 高频查询加密字段时，
DECRYPTBYKEY比普通SELECT慢 3–5 倍；别全表解密扫描，考虑加哈希列做前置过滤
别把哈希当加密，也别指望子查询“自动加密比对”
HASHBYTES 是单向的，不能还原原始数据；WHERE encrypted_col = ENCRYPTBYKEY(...) 这种写法会让索引失效、密钥暴露、跨版本行为不一致。
- 哈希只适合密码校验或脱敏，比如存
HASHBYTES('SHA2_512', CONCAT(@pwd, @salt))，盐值必须每用户独立生成、单独存 - 子查询不能绕过加密位置限制：加密必须在应用层完成，数据库只负责安全存储和等值比对（且需固定 IV、统一字符集、显式类型）
- MySQL 的
AES_ENCRYPT在 WHERE 中动态调用，会触发全表扫描；SQL Server 的ENCRYPTBYPASSPHRASE同样无法索引，密文长度还不固定
真正难的不是写对那几行 OPEN SYMMETRIC KEY，而是确保密钥生命周期、权限链、类型转换、错误静默这四件事，在每一次存储过程调用中都稳住——它们不会报错，只会悄悄返回 NULL。
