必须在DECRYPTBYKEY前紧邻执行OPEN SYMMETRIC KEY并检查密钥状态，解密后显式转换类型，且用户需同时具备证书VIEW DEFINITION和密钥REFERENCES权限。
不能直接在存储过程中对加密字段做“动态解密 + 授权判断”一体化处理——ENCRYPTBYKEY/DECRYPTBYKEY 本身不支持按用户身份自动切换密钥或权限上下文，必须显式控制密钥打开、权限检查和类型转换三步，漏任何一环都会返回 NULL 或乱码。
OPEN SYMMETRIC KEY 必须在每次调用 DECRYPTBYKEY 前执行
SQL Server 不会跨语句保持密钥打开状态，哪怕刚在上一行 OPEN SYMMETRIC KEY 过，下一句 DECRYPTBYKEY 仍可能失败。常见错误是把密钥打开写在存储过程开头，但中间有 IF 分支、RETURN 提前退出、或事务回滚（ROLLBACK 会隐式关闭所有已打开密钥）。
- 必须在
DECRYPTBYKEY所在语句前紧邻位置执行OPEN SYMMETRIC KEY your_key DECRYPTION BY CERTIFICATE your_cert - 加前置检查：用
IF NOT EXISTS (SELECT * FROM sys.openkeys WHERE key_name = 'your_key')包裹打开逻辑，避免重复打开报错 - 不要依赖存储过程级变量缓存密钥状态——它不生效
DECRYPTBYKEY 返回 VARBINARY，必须显式转成字符串
即使密钥打开了、权限也够，DECRYPTBYKEY 结果仍是 VARBINARY，直接 SELECT 或赋值给 NVARCHAR 变量会触发静默截断或乱码。前端看到的“空值”或“”往往就卡在这步。
- 解密后立刻用
CONVERT(NVARCHAR(MAX), DECRYPTBYKEY(...))或CAST(... AS NVARCHAR(MAX)) - 如果目标字段是
NVARCHAR(100)，别省略长度：用CONVERT(NVARCHAR(100), ...)避免超长截断 - 明文原始长度超过约 7900 字节时，
ENCRYPTBYKEY已无法处理，解密必然失败——这不是权限问题，是输入超限
用户必须同时具备 VIEW DEFINITION（证书）和 REFERENCES（密钥）权限
能执行 ENCRYPTBYKEY 不代表能执行 DECRYPTBYKEY。权限检查发生在运行时，且不随 EXECUTE AS 自动继承。
- 执行用户需对证书有
VIEW DEFINITION，对对称密钥有REFERENCES——缺一不可 - 若存储过程用了
EXECUTE AS OWNER，则 owner 用户也得被授予这两项权限（不能只授给调用者） - 用
SELECT * FROM sys.fn_my_permissions(NULL, 'DATABASE')检查当前会话实际权限，别只看角色成员关系
别在 WHERE 条件里用 DECRYPTBYKEY 做过滤
像 WHERE CONVERT(NVARCHAR, DECRYPTBYKEY(encrypted_col)) = @input 这种写法会让索引失效、全表扫描、性能暴跌，且暴露密钥使用模式。
- 高频查询场景下，应额外建哈希列（如
HASHBYTES('SHA2_512', @plain)）用于等值匹配，再对命中行单独解密 -
HASHBYTES是单向的，不能还原原文，只适合校验或脱敏，别拿它替代加密字段 - 绝对不要写
WHERE encrypted_col = ENCRYPTBYKEY(@input)——密钥未打开时整个表达式为 NULL，逻辑崩坏
最易被忽略的一点：密钥打开作用域仅限当前会话，且无法跨批处理（GO 分隔）、跨 RPC 调用或跨连接复用。哪怕你在 SSMS 同一个窗口里先手动开了密钥，再 EXEC 存储过程，过程内部仍视为未打开——必须在过程体内自己开。
