0

列がproduct同じテーブルがあります。主キーはproductid. 50,000 行ありますが、そのような select ステートメントを発行するselect * from productsと、完全なデータを取得するのに 10 分かかります。その結果、クエリをより高速に実行できるようになるため、何をすべきかアドバイスしてください。

4

3 に答える 3

0

主キーはそのテーブルのクラスタリングキーでもありますか?

あなたがそうするならば、SELECT * ....あなたは基本的に常に全表スキャンを得るでしょう。そのクエリを高速化できるものは実際にはありません-すべての行、すべての列が必要です-したがって、すべてを取得し、それにかかる時間がかかります。

あなたがより「焦点を絞った」クエリを行う場合

SELECT col1, col2 FROM dbo.Products WHERE SomeColumn = 42

次に、適切なインデックスを使用してこれを高速化するチャンスがあります。

于 2012-07-03T09:23:53.937 に答える
0

より良いコンピューターを購入する。

真剣に。

SQL Server 2000は数年前に廃止されたため、これは古いインストールです。50.000の製品は冗談です-100万未満のテーブルは何もありません。

しかし、製品からselect *のようなselectステートメントを発行すると、完全なデータを取得するのに10分かかります。

これが低速のインターネット接続ではなくLAN経由であると仮定すると、次の2つの理由が考えられます。

  • システムがひどく過負荷になっています。深刻な過負荷のように。私が古いセットアップでそれを見たことがないようではありません。そこに行ってみました-ハードディスクが非常に過負荷になっているため(SCSIであり、高速です)、要求に応答するのに2秒以上かかりました。
  • システムは無能な人によってプログラムされています。トランザクションレベルの処理が不適切で、長期間にわたってひどいロックが発生し、ブロックされる可能性があります。これは可能ですが、それからあなたはプログラミングからばかげたコードを取り除くためにたくさんのやり直しをしなければなりません。

テーブルからのselect*は、LANを介してすべてのデータを転送するのに数秒以上かかることはありません。点。ベールに大量のバイナリデータが含まれていない限り(つまり、一部のフィールドに大量のデータが含まれている場合)。

分析を行うためのローカルデータベーススペシャリストとして。ハードウェアの負荷から始めて、ロック動作に移ります。より現代的なテクノロジーへのアップグレードを検討してください。今では、あなたは何世代も遅れています。

于 2012-07-03T09:24:38.453 に答える
-2

基準(WHERE)がないため、クエリにかかる時間は、選択(選択する行の決定)によるものではなく、データのサイズが原因である可能性があります。

唯一の解決策は次のとおりです。

を使用せずSELECT *、必要な列のみを選択してください。

于 2012-07-03T09:25:55.347 に答える