0

データベースに10kレコードのテーブルがあるとしましょう。これらの10kレコードを実際に使用する必要はもうありませんが、データベースに保持する必要があります。そのテーブルは、新しいデータを格納するために使用されます。したがって、テーブルにすでに存在する10Kレコードの上にさらに多くのレコードが追加されることになります。「古い」10Kレコードとは対照的に、新しく挿入されたデータを処理する必要があります。今、私は必要なデータを取得するためにこれを行っています:

List<Stuff> l = (from x in db.Table
            where x.id > id
            select x).ToList();

私の質問は、LINQ(またはSQL一般)の句が内部でどのように機能するかということです。where真になるまでテーブル全体が検索され(x.id > id)ますか?テーブルが10kレコードから20Kに増加するとします。特定のポイントから調べ始めるだけでよいことがわかっている場合、20kレコード全体を調べるのは少しばかげています。

LINQ toエンティティを使用しているときに、これでパフォーマンスの問題が発生しました(劇的ではありませんが、それによって動揺するほど悪いです)。たった2万レコード。LINQクエリの代わりにストアドプロシージャを使用するようにアドバイスされましたが、これによってパフォーマンスが向上するかどうかわかりませんか?

フィードバックをいただければ幸いです。

4

1 に答える 1

2

これは、同様の SQL クエリと同じように動作します。問題は、発生しているオーバーヘッドがクエリで発生しているのか、クエリからリストへの変換で発生しているのかということです。あなたが書いたクエリ自体は、文字通り次のようになります。

Select ID, Column1, Column2, Column3, ... , Column(n+1)
From db.Table
Where ID > id

このクエリは、データの性質によってはかなり高速になるはずです。ただし、クエリ自体は実行されるまで実行されません。この場合、それをリストに変換しています。これは、それに基づいて操作するのと同じです。このプラクティスについて誰かが私に寄せたコメントは見つかりませんが、パフォーマンスをクリーンに保つのに非常に役立つことがわかりました. 非常に具体的な必要がない限り、クエリはそのままにしておく必要がありますIQueryableIEnumerableそれらをリストに変換すると、最初にクエリを実行し、次に結果セットを適切な(この場合はリスト) に変換する必要があるため、手間が 2 倍になります。

したがって、2 つの潜在的なボトルネックがあります。単純なクエリでは、大量のデータ コレクションをクエリするのに時間がかかったり、リストが作成される場所でレコード数がボトルネックになったりする可能性があります。別の可能性は、IDこの場合の性質です。数値の場合は、時間を節約できます。テキストベースの検索を実行している場合は、より重くなります。

特定の質問に答えるために、はい、データベース内のすべてのレコードを検索し、式に一致するすべてのレコードを返します。編集:データベースが問題の列に適切なインデックスを持っている場合、すべてのレコードを検索するのではなく、インデックスを使用して検索を実行します。@Pleun からのコメントから。

ストアド プロシージャの使用に関しては、それはごちゃごちゃした負荷ですが、完全に許容できる代替手段です。4,000 万を超えるレコードを持つデータベースに対して同様のクエリを定期的に実行するプログラムがいくつかありますが、これまでに遭遇した唯一のパフォーマンスの問題は、複数のユーザーがクエリを高速で実行している場合の CPU 使用率でした。特定の問題を解決するには、必要なクエリが許容できる速度でインターフェイスに戻るまで、SQL Management Studio で少し調整することをお勧めします。次に、そのクエリを互換性のある Linq ステートメントに変換できます。そのままにしておく限り、IQueryable同様の結果が得られるはずです。

于 2012-06-20T18:31:48.670 に答える