1

我有一个从 .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);
4

7 回答 7

3

我怀疑这是一个过程缓存问题。存储过程的一个好处是计划是为您存储的，这可以加快速度。不幸的是，有可能在缓存中得到一个糟糕的计划（即使使用动态查询）。

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

试试这个....

连接到 SQL Server Management Studio。

DBCC MemoryStatus

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

dbcc MemoryStatus

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

dbcc MemoryStatus

我想您会发现 TotalProcs 会在语句更改时发生更改（即使唯一的更改是区分大小写的）。

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

于 2008-09-29T20:04:19.187 回答
1

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

于 2008-09-29T18:36:09.257 回答
1

我没有看到您的查询有影响性能的差异 - 运行之间的缓存或索引/统计数据变化怎么样？由于统计信息或索引更改，执行计划可能已更改。

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

于 2008-09-29T18:38:32.123 回答
0

首先，您是否 100% 确定查询出错了？检查 sql server 中的跟踪配置文件，看看它在数据库中占用了多长时间。

其次，您是否获得了相同数量的结果。默认情况下，大写在 sql server 中应该无关紧要，但它可以设置不同。

于 2008-09-29T18:39:26.893 回答
0

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

于 2008-09-29T18:40:51.960 回答
0

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

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

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

3）Joel Coehoorn，同意，但我在这里真正想要了解的是“为什么”，因为现在我们不知道这个问题有多大以及它在哪里。

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

于 2008-09-29T19:04:10.297 回答
0

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

谢谢大家的帮助！

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

于 2008-09-29T22:12:55.040 回答