对Always Encrypted列使用带ToLower的Linq查询报错如何解决

• Always Encrypted（始终加密）的加密解密逻辑完全在客户端执行，SQL Server服务端仅存储加密后的密文，无法对加密列的明文执行任何运算。你编写的x.Email.ToLower()会被EF默认翻译为SQL层面的LOWER()函数，该函数需要在服务端执行，无法作用于加密后的密文，同时生成的SQL参数类型与加密列的nvarchar类型不匹配，最终触发类型冲突报错。
• 原始的等值查询可以正常运行，是因为你使用了确定性加密：相同明文加密后得到的密文完全一致，EF会先在客户端将传入的userEmail加密为密文，再将密文传给SQL Server做密文的等值比对，整个过程不需要服务端操作明文，符合始终加密的使用限制。

方案1：存储时统一格式化字符串（最推荐） #

提前在写入加密列时就将字符串统一转为全小写/全大写，查询时先将入参转为对应格式后直接做等值匹配，不会触发服务端函数运算，性能无损失。
示例代码：

// 写入数据时统一转小写
user.Email = inputEmail.ToLowerInvariant();

// 查询时先转传入参数，再做等值匹配
var lowerUserEmail = userEmail.ToLowerInvariant();
var matchedUser = appDbContext.Users.FirstOrDefault(x => x.Email == lowerUserEmail);

方案2：客户端内存比对（仅适合小数据量场景） #

如果无法修改存量数据的存储格式，可以先将需要比对的数据集加载到客户端内存，再在内存中执行大小写不敏感比对。注意该方案会加载符合前置过滤条件的全量数据，数据量较大时性能极差。
示例代码：

// 先通过其他非加密列的过滤条件缩小数据范围，再加载到内存
var candidateUsers = appDbContext.Users.Where(/* 其他业务过滤条件 */).ToList();
var matchedUser = candidateUsers.FirstOrDefault(x => x.Email.Equals(userEmail, StringComparison.OrdinalIgnoreCase));

• 不要对始终加密列使用任何字符串处理方法（ToLower/ToUpper/Contains/SubString等），这类方法都会被EF翻译为服务端SQL函数，无法执行。
• 确定性加密仅支持等值查询，不支持范围查询、模糊查询等运算，如果业务需要这类能力需要提前调整加密策略或业务逻辑。

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