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

私はこの例外を受け取ります：

タイムアウトが期限切れになりました。操作が完了する前にタイムアウト期間が経過したか、サーバーが応答していません。

比較の前に連結が必要な最初のクエリが、比較以外の何もしなければならない2番目のクエリよりも高速であるとは信じられません。なぜこれが起こっているのか教えていただけますか？

役立つかもしれないいくつかの情報：

  • PRSNumber主キーはvarchar(11)であり、主キーです
  • ProjectCodeはnvarchar(10)
  • どちらのクエリもSQLServerManagementStudioで正常に機能します
  • 最初のクエリはASP.NETWebサイトで機能しますが、2番目のクエリは機能しません
  • 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

CommandTimeoutクエリを高速化する代わりに、SqlCommandのプロパティを高く設定しました。速度は解決しませんでしたが、タイムアウトの問題は解決しました。

于 2012-06-07T06:03:19.313 に答える