encryptbykey必须先执行open symmetric key显式打开密钥，否则返回null；加密结果为varbinary，目标列须为varbinary(8000)，解密需view definition和references权限。
ENCRYPTBYKEY 为什么必须先打开对称密钥
直接调用 ENCRYPTBYKEY 却返回 NULL，八成是密钥没打开。SQL Server 不会自动加载对称密钥，哪怕它已存在且已加密——你得显式执行 OPEN SYMMETRIC KEY，并确保会话上下文里它处于“已打开”状态。
常见错误现象：存储过程里反复调用 ENCRYPTBYKEY 却始终加密失败，查日志发现没报错，只返回空值；或者只在第一次调用成功，后续全为 NULL（因为密钥在上一次操作后被意外关闭或超时释放）。
- 必须在加密前执行
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')做前置检查，避免重复打开报错 - 密钥打开后默认有效期为当前会话生命周期；若存储过程中有事务回滚、异常跳转或长耗时逻辑，需确认密钥未被隐式关闭
加密字段类型必须用 VARBINARY(最大长度)
ENCRYPTBYKEY 返回的是二进制数据，不是字符串。如果把结果 INSERT 进 NVARCHAR 或 VARCHAR 字段，SQL Server 会静默执行字符集转换，导致解密时提示 Invalid key or certificate 或直接返回 NULL。
使用场景：比如加密身份证号、手机号、邮箱等文本型敏感字段，不能图省事沿用原字段类型。
- 目标列类型必须声明为
VARBINARY(8000)（足够覆盖 AES_256 加密后的膨胀长度） - 插入前务必用
CONVERT(VARBINARY(8000), @plain_text)显式转码，而不是依赖隐式转换 - 若原始数据可能超长（如长地址），注意
ENCRYPTBYKEY对输入长度有限制：AES 算法下明文最大约 7900 字节（受填充和头部开销影响）
DECRYPTBYKEY 解密时容易忽略的权限与上下文问题
能加密不等于能解密。即使存储过程里正确打开了密钥，DECRYPTBYKEY 仍可能返回 NULL，原因常不在函数本身，而在执行者权限或证书绑定关系。
性能影响：每次解密都触发密钥解封和算法运算，比普通 SELECT 慢 3–5 倍；若高频查询加密字段，应考虑加索引列（如哈希值）做前置过滤，而非全表解密扫描。
- 执行用户必须对证书有
VIEW DEFINITION权限，对对称密钥有REFERENCES权限 - 若存储过程用
EXECUTE AS OWNER，需确保 owner 用户也拥有上述权限（权限不继承） - 解密结果是
VARBINARY，需再用CONVERT(NVARCHAR, ...)转回文本，漏掉这步会导致前端看到乱码字节流
如何安全地在存储过程中封装加解密逻辑
直接把 ENCRYPTBYKEY 和 DECRYPTBYKEY 暴露给应用层风险高——密钥名、证书名、甚至加密逻辑都可能被逆向或误用。推荐在存储过程中封装为原子操作，并限制参数注入面。
容易踩的坑：有人用动态 SQL 拼接密钥名，结果被注入攻击绕过权限控制；或把明文直接作为参数传入，导致敏感内容出现在 Profiler 或扩展事件日志中。
- 密钥名、证书名写死在存储过程中，不通过参数传入；确需多密钥支持，用白名单 CASE 分支控制
- 对输入参数做长度截断（如
LEFT(@input, 100)）和空值校验，防止超长输入触发异常或拒绝服务 - 加密操作尽量靠近数据写入点（如
INSERT前一刻），避免明文在变量中驻留过久；解密仅在必要查询分支中执行
复杂点在于密钥轮换——ENCRYPTBYKEY 不支持指定版本，旧数据无法自动识别用哪个密钥加密。一旦更换密钥，必须同步迁移历史数据，这点常被忽略。
