0

我们有一个名为Purchases：

| PRSNumber   | ... | ... | ProjectCode |
| PRJCD-00001 |     |     | PRJCD       |
| PRJCD-00002 |     |     | PRJCD       |
| PRJCD-00003 |     |     | PRJCD       |
| PRJX2-00003 |     |     | PRJX2       |
| PRJX2-00003 |     |     | PRJX2       |

注：ProjectCode是 的前缀PRSNumber。

之前，当表中没有ProjectCode字段时，我们以前的开发人员使用此查询来搜索特定供应商的采购：

select * from Purchases where left(PRSNumber,5) = @ProjectCode

是的，他们连接PRSNumber以获取和比较ProjectCode. 虽然，无论表格设计如何，上面的代码都可以正常工作。

但是当我添加一个新字段时，ProjectCode, 并使用此查询：

select * from Purchases where ProjectCode = @ProjectCode

我收到此异常：

超时已过。在操作完成之前超时时间已过或服务器没有响应。

我不敢相信，在比较之前需要连接的第一个查询比除了比较什么都不做的第二个查询要快。你能告诉我为什么会这样吗？

一些可能有用的信息：

  • PRSNumber是varchar(11)并且是主键
  • ProjectCode是nvarchar(10)
  • 这两个查询在 SQL Server Management Studio 中都能正常工作
  • 第一个查询在 ASP.NET 网站中有效，但第二个查询无效
  • ProjectCode被索引
  • 该表有 32k 行

更新

  • ProjectCode现在已编入索引，仍然没有运气
4

2 回答 2

1

我要做的第一件事是检查 PRSNumber 上的索引，我假设该字段上有一个索引并且表非常大。

向新字段添加索引可能会解决问题（如果是这样的话）。

添加索引的代码：

CREATE INDEX IX_Purchases_ProjectCode 
ON dbo.Purchases (ProjectCode);

更新：

我还会尝试将该字段添加为 varchar 以消除等式中的数据类型更改。

于 2011-09-24T07:05:45.760 回答
0

我将CommandTimeoutSqlCommand 的属性设置得更高，而不是使查询更快。它没有解决速度问题，但解决了超时问题。

于 2012-06-07T06:03:19.313 回答