使用 OleDB 从 .NET 查询 SQL Server 2005 时的区分大小写

Question

我有一个从 .NET 应用程序到 SQL Server 数据库执行的查询，它似乎需要相当长的时间才能完成（5 分钟以上）。 我在 C# 中创建了一个测试应用程序，尝试查看这么长的内容（查询应该很快返回）。

当我通过添加元素来重建查询以查看哪个部分花费了这么长时间时，我最终几乎逐字重建了查询，其中唯一的区别是原始查询中的空格和大小写差异。 此差异在大约 100 毫秒内返回结果。

有人见过这个吗？ 我想知道我们的服务器或我们的计算机上是否有服务被关闭（因为同事有同样的问题）。

预先感谢您对此提供的任何帮助。

下面的代码示例（最后查询第一行的差异（fk_source 与 fk _Source）：

//Original
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >=  CONVERT(datetime,'01-01-2008',105)  and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105)  and s.c_id = '27038dbb19ed93db011a315297df3b7a'", dbConn);

//Rebuilt
    OleDbCommand comm = new OleDbCommand("select min(ctc.serial_no) as MIN_INTERVAL from countstypecode ctc, source s, countstype ct, counts c where ct.value_id=c.value_id and s.c_id=ct.fk_Source and " +
      "ct.timeinterval=ctc.typename and ct.timeinterval in ('15min','1h','1day') and c.time_stamp >= CONVERT(datetime,'01-01-2008',105) and c.time_stamp < " +
      "CONVERT(datetime,'01-01-2009',105) and s.c_id='27038dbb19ed93db011a315297df3b7a'", dbConn);

Answer 1

我怀疑这是一个过程缓存问题。 存储过程的好处之一是为您存储计划，从而加快速度。 不幸的是，缓存中可能会出现错误的计划（即使使用动态查询时）。

只是为了好玩，我检查了我的过程缓存，运行了一个临时查询，再次检查，然后我用不同的大写运行了相同的查询，我惊讶地发现过程计数更高。

试试这个...

连接到 SQL Server Management Studio。

DBCC MemoryStatus

Select Columns... From TABLES.... Where....

dbcc MemoryStatus

Select Columns... From tables.... Where....

dbcc MemoryStatus

我认为您会发现当语句更改时 TotalProcs 也会更改（即使唯一的更改区分大小写）。

更新您的统计数据可能会有所帮助。 这是一个相当慢的运行过程，因此您可能希望在缓慢的时期运行它。

Answer 2

由于您使用的是 SQL Server 2005，您是否尝试过使用 SqlCommand 对象而不是 OleDbCommand 对象？

Answer 3

我没有看到您的查询存在会影响性能的差异 - 运行之间的缓存或索引/统计信息变化如何？ 执行计划可能由于统计数据或索引变化而发生变化。

关于情况：如果数据库设置为区分大小写，则大小写可能很重要，但是对于在区分大小写的数据库中运行的两个查询，必须有以两种格式命名的列 - 查询解析器将遵守大小写 -它不会导致性能差异。

Answer 4

首先，您是否 100% 确定查询出了问题？ 检查 sql server 中的跟踪配置文件以查看其在数据库中花费的时间。

其次，您是否得到相同数量的结果。 默认情况下，大小写在 sql server 中并不重要，但可以进行不同的设置。

Answer 5

如果我有一个需要“5 分钟以上”的查询，我就不会担心匹配字符串大小写所需的 100 毫秒。

Answer 6

感谢您的所有回答，我将依次回复：

1）Russ，我同意 SQLConnection 会更好，但不幸的是我无法设置连接类型。 我刚刚创建了一个小应用程序来测试此查询，但该查询是在更大的应用程序中动态创建的。

2）gbjbaanb，我认为这不是服务器问题，因为我可以在大约同一时间从管理工作室运行两个查询，只有在.net（1.1和2.0）中通过oledb运行时这似乎才是问题。 我们对其运行了探查器，跟踪文件确认以这种方式调用时需要 5 分钟以上才能完成查询。

3）乔尔·科霍恩（Joel Coehoorn），同意，但我真正想知道的是“为什么”，因为现在我们不知道这个问题有多大以及它在哪里。

4)Cade Roux，差异是非常可重现的，所以我不认为这是索引更改或缓存的问题，因为我已经连续运行测试并得到相同的结果，并且它们在 SQL Server 中花费了大约相同的时间跑步。

Answer 7

感谢 G Mastros 提供了最完整的答案，尽管回想起来，统计数据的更新是由 Cade 建议的。 然而，G Mastos 的解决方案更适合我的 SQL Server 经验水平。

感谢大家的帮助！

我将研究为什么这种看似无辜的差异会产生如此大的后果