我有一个查询，我正在从.NET应用程序执行到SQL Server数据库，并且似乎要花很长时间才能完成(5分钟以上)。我在cto中创建了一个测试应用程序，以尝试查看通话时间已久(查询应迅速返回)。

当我通过添加元素以查看哪个部分花费了如此长的时间来重建查询时，我最终几乎逐字重建了查询，其中唯一的区别是原始查询中的空格和大小写差异。这种差异在大约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);

解决方案

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

我没有看到查询中的差异会影响性能，但是两次运行之间的缓存或者索引/统计信息变化又如何呢？由于统计信息或者索引更改，执行计划可能已更改。

关于大小写：如果将数据库设置为区分大小写，大小写可能很重要，但是要使两个查询都在区分大小写的数据库中运行，则查询解析器必须服从用两种格式命名的列，否则查询解析器将服从它的情况不会造成性能差异。

首先，我们是否100％确定其查询出了问题？检查sql服务器中的跟踪配置文件，以了解其占用数据库多长时间。

其次，我们是否获得了相同数量的结果。默认情况下，在sql server中，大小写无关紧要，但是可以将其设置为其他方式。

如果我的查询花费了" 5分钟以上"的时间，那么我就不必担心匹配字符串大小写需要100毫秒的时间。

感谢所有回答，我将依次回答每个问题：

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

2)gbjbaanb，我认为这不是服务器问题，因为我可以同时在Management Studio中运行两个查询，这似乎仅在通过.net(1.1和2.0)中的oledb运行时才出现问题。我们已经在其上运行了探查器，并且以这种方式调用时，跟踪文件确认已花费了5分钟以上的时间来完成查询。

3)乔尔·科荷恩(Joel Coehoorn)，同意，但实际上我想表达的是"为什么"，因为现在我们不知道这个问题的严重性和所在位置。

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

我怀疑这是一个过程缓存问题。存储过程的好处之一是为我们存储了计划，从而加快了工作速度。不幸的是，有可能在缓存中获得错误的计划(即使使用动态查询时)。

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

试试这个....

连接到SQL Server Management Studio。

DBCC MemoryStatus

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

dbcc MemoryStatus

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

dbcc MemoryStatus

我认为我们会发现，当语句更改时，TotalProcs也会更改(即使唯一的更改是区分大小写的)。

更新统计信息可能会有所帮助。这是一个相当慢的运行过程，因此我们可能需要在很慢的时间内运行它。

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

感谢我们对大家的帮助！

我将研究为什么这种看似天真的差异会带来如此大的后果