我有我从.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);
我怀疑这是一个过程缓存问题。 存储过程的一个好处是，该计划被保存为你，从而加快东西。 不幸的是，有可能得到一个坏计划在缓存中（即使使用动态查询时）。
只是为了好玩，我检查了我的过程高速缓存，跑了即席查询，检查了一遍，然后我跑了不同capitlization相同的查询，我很惊讶地看到程序计数较高。
尝试这个....
连接到SQL Server Management Studio中。
DBCC MemoryStatus
Select Columns... From TABLES.... Where....
dbcc MemoryStatus
Select Columns... From tables.... Where....
dbcc MemoryStatus
我想你会发现，当TotalProcs更改了该语句的变化（即使在唯一的变化是区分大小写）。
更新您的统计数据可能会有所帮助。 这是一个相当缓慢的运行过程中，所以你可能需要在一个时期缓慢运行。
由于使用的是SQL Server 2005中，你有一个SqlCommand对象，而不是OleDbCommand对象试过吗？
我没有看到在查询一个差，这会影响性能 - 怎么样运行之间的缓存或索引/统计数据的变化？ 执行计划可能发生了变化，由于统计数据或指标的变化。
关于案例：如果数据库设置为区分sensistive情况下，可以无所谓，但对于这两个查询在区分大小写的数据库上运行，就必须在这两种格式命名的列 - 查询分析器将遵守情况 - 它不会造成性能上的差异。
首先，你是100％肯定它是走错了查询？ 检查跟踪配置文件在SQL Server中看到其采取在DB多久。
其次，你得到相同的结果数回。 资本化不应该在默认情况下在SQL Server的关系，但它可能已经设立不同。
如果我有把“5+分钟”的查询，我不会担心它需要字符串的情况下匹配了100毫秒。
感谢所有的答案，我会依次向每个回应：
1）拉斯，我同意在该SQLConnection会更好，但不幸的是我没有得到设置连接类型。 我刚刚创建了一个小的应用程序来测试该查询，但在一个更大的应用程序动态创建的查询。
2）gbjbaanb，这不是一个服务器的问题，我认为，是因为我可以在大约同一时间运行从管理工作室两个查询，似乎只有当通过OLEDB在.NET（1.1和2.0）运行是一个问题。 我们已经在其上运行探查器和跟踪文件证实，它接管5分钟完成查询调用该方法时。
3）乔尔Coehoorn，表示同意，但真的是我试图让在这里是“为什么”，因为现在我们不知道这个问题有多大以及它所在。
4）凯德鲁，所不同的是非常reproduceable，所以我不认为这是与指数的变化或高速缓存的问题，因为我已进行的测试回来了相同的结果来支持并采取有关SQL Server的同时跑。
由于至G Mastros为最完整的答案，但在事后统计的更新是由凯德建议。 摹Mastos的解决方案更适合我的SQL Server的经验水平，但是。
感谢您的帮助大家！
我要去寻找到为什么这种看似无辜的差异有这么大的后果
