一、两种查询方式谁更高效？ #

先抓你给出的核心前提：MD5是唯一的，这直接决定了答案。

• 第二种只查MD5的查询（ctx.Files.FirstOrDefault(x=> x.MD5.Equals(md5))）肯定更高效。原因很简单：MD5本身就能定位到唯一一行，数据库不需要再去比对FileSize——第一种查询多出来的FileSize条件，不仅帮不上忙（毕竟结果集已经是唯一的），反而会让数据库在找到目标行后多做一次额外判断，平白增加了一点点开销。
• 当然，如果你给(FileSize, MD5)建了联合索引，第一种查询也能用上索引，但因为MD5是唯一的，单独的MD5索引在检索时的开销还是更小：联合索引的键长度更长，索引占用的磁盘空间更大，检索时的IO成本也会略高。

二、要不要写原生SQL？ #

大概率不需要。EF6处理这种简单的单条件查询时，生成的SQL已经足够高效，而且能正确利用你建的索引。除非你碰到了EF对MD5这种二进制类型的处理bug（比如参数类型匹配有问题），否则完全没必要手写原生SQL。真要纠结的话，也可以用EF的原生SQL查询方法，但属于多此一举的情况。

三、怎么把这种键值检索的性能拉到最大？ #

核心就是索引+字段类型+查询习惯的优化，给你列几个关键措施：

• 给MD5字段建唯一非聚集索引：因为MD5唯一，唯一索引既能保证数据不重复，又能让数据库以最快速度定位到目标行。重点注意MD5的存储类型：别用字符串存！你的示例里是二进制格式，直接用VARBINARY(16)（MD5正好是16字节），字符串存储会多占空间，索引效率差很多。
• 别加多余条件：就像第一种查询里的FileSize，既然MD5已经能唯一确定行，加这个条件纯纯是画蛇添足，只会增加数据库的判断成本，完全没必要。
• 选对主键和索引类型：如果你的业务是读多写少，而且MD5是最常用的检索键，可以考虑把MD5设为主键（聚集索引）；但如果写入频繁，MD5的随机性会导致聚集索引页分裂，影响写入性能，这时候还是用自增Id当主键，给MD5建唯一非聚集索引更合适。
• 用AsNoTracking()减少开销：如果只是查数据不需要修改，给查询加上AsNoTracking()，能关掉EF的上下文跟踪，节省一点内存和CPU开销，比如写成：ctx.Files.AsNoTracking().FirstOrDefault(x=> x.MD5.Equals(md5))。
• 依赖EF的参数化查询：EF6默认会把查询参数化，这不仅能防SQL注入，还能让数据库缓存查询计划，重复查询时速度更快——这点不用你操心，EF已经帮你做好了。

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