SQL Server：Always Encrypted存储过程列/变量加密方案不匹配问题

看起来你在启用Always Encrypted适配英国法规后，遇到了两个关联的棘手问题：加密方案不匹配错误，以及创建存储过程时的语法/元数据缺失错误。我来帮你逐个拆解分析，给出实用的解决方案：

一、加密方案不匹配错误（Encryption scheme mismatch） #

这个错误的核心根源是Always Encrypted的设计逻辑：加密列的解密/加密操作是在客户端应用层完成的，SQL Server实例本身无法直接读取或修改加密列的明文值。

你单独执行查询时能正常运行，是因为你的客户端（比如SSMS）已经启用了Always Encrypted，自动帮你完成了解密操作。但存储过程是在SQL Server端执行的，默认情况下它没有权限访问加密列的明文，所以当你在存储过程里直接给变量赋值加密列时，就会触发加密方案不匹配的错误。

可行解决办法 #

你可以根据自身环境选择合适的方案：

• 客户端前置取值再传入存储过程：把查询ParameterValue的逻辑移到应用端，拿到明文的EXPORT_PATH后，再作为参数传给存储过程。这是最轻量化的方案，不需要修改数据库配置。
• 使用Always Encrypted with Secure Enclaves（SQL Server 2019+）：如果你的SQL Server版本支持，可以启用安全飞地功能，它允许SQL Server在隔离的安全环境中处理加密列的计算。这样存储过程就能直接操作加密列了，不过需要额外配置服务器和密钥权限。
• 原生编译存储过程（内存优化数据库）：如果你的数据库是内存优化模式，可以创建原生编译的存储过程，并启用ENCRYPTED选项，让SQL Server能处理加密列的操作。不过这个方案有数据库类型的限制。

二、创建存储过程时的语法及元数据错误 #

你创建SIMONTEST存储过程时遇到的Msg 156和元数据缺失错误，主要是因为创建存储过程时的连接没有启用Always Encrypted。

当你创建涉及加密列的存储过程时，客户端必须启用Always Encrypted，这样SQL Server才能正确识别加密列的元数据，生成合法的存储过程定义。如果连接没启用这个设置，SQL Server会无法解析加密列的类型，进而抛出语法或元数据错误。

具体解决步骤 #

1. 启用连接的Always Encrypted设置：
   • 如果用SSMS连接数据库：在“连接到服务器”窗口点击“选项”，切换到“附加连接参数”标签，添加ColumnEncryption Setting=Enabled；或者在“连接属性”里勾选“启用Always Encrypted（列加密）”。
   • 如果用SQLCMD：执行命令时加上参数-ColumnEncryption Setting=Enabled。
2. 确保变量类型与加密列完全匹配：检查ParameterValue列的数据类型，确保存储过程里的@FilePath变量类型（比如VARCHAR(8000)）和它完全一致，包括长度、是否为Unicode等。
3. 验证密钥可用性：确认列主密钥（CMK）和列加密密钥（CEK）是有效的，SQL Server有访问它们的权限（比如CMK存在Azure Key Vault的话，要确保服务器有对应的访问权限）。

完成以上步骤后，重新创建存储过程，应该就能正常执行了。

内容的提问来源于stack exchange，提问作者Simon Price