C# 用“选择”；日期时间>；“字符串”；EF4/SQL Server 2008中的性能问题

我正在使用EntityFramework 4访问SQL Server 2008数据库

EF生成的一个SQL查询具有我无法解释的行为。 查询如下：

SELECT tableA.field1, tableA.field2, ...
FROM tableA join tableB on tableA.field1 = tableB.field1
WHERE
    tableA.field2 > '20110825'
    and tableA.field3 in ('a', 'b', 'c,')
    and tableB.field4 = 'xxx'

其中tableA.field2为

datetime not null

，其他字段为varchars。 tableA包含大约150万条记录，tableB包含大约200万条记录，查询返回1877行

问题是，它在86秒内返回它们，当我将“20110825”文本更改为旧值时，时间会发生巨大变化

例如，如果我输入'20110725'，查询将在35毫秒内返回3483行

我在执行计划中发现，两者的区别在于SQL Server根据用于比较的日期选择使用的索引

当需要时间时，执行计划显示：

• 50%：表a.field2上的索引查找（仅此字段上为聚集索引）
• 50%：表B.field1上的索引查找（仅此字段上的索引为非唯一、非聚集索引）
• 0%：加入

当几乎是瞬间时，执行计划显示：

• 98%：表A.field1上的索引查找（仅此字段上的索引为非唯一、非聚集索引）
• 2%：表B.field1上的索引查找（仅此字段上的索引为非唯一、非聚集索引）
• 0%：加入

因此，在我看来，优化器使用tableA.field2上的聚集索引的决定不是最优的

数据库设计中是否存在缺陷？在SQL查询中

---

我可以以任何方式强制数据库使用正确的执行计划吗？

鉴于您使用的是文字值，并且仅遇到最近日期字符串的问题，我怀疑您遇到了问题，需要安排作业来更新统计信息

---

据推测，当它们上次更新时，很少或没有符合

'20110825'

标准的行，SQL Server正在使用基于该假设的连接策略。

是的，这就是想法。由于缺少统计信息更新，SQL优化器错误地使用了基于日期的索引。由于数据库是我店业务的核心，我建议他们考虑每日更新工作的想法，但与此同时，我将强制使用“正确”索引，在两个表上用索引调用。