1

基本的に私のアプリケーションでは、次のコードを使用して、ページでの選択に応じて式を作成しています。

Expression<Func<T, bool>> expr = PredicateBuilder.True<T>();
expr = expr.And(b => b.Speed >= spec.SpeedRangeFrom && b.Speed <= spec.SpeedRangeTo);
...

複数の「or」および「and」条件を含む長い式になる傾向があります。

式の作成が完了したら、次のようなリポジトリに渡しました。

var results = Session.Query<T>().Where(expr).ToList();

それに関する問題は、結果を返すのに非常に時間がかかることです。また、式が長いほど、結果セットを返すのに時間がかかることにも気付きました。

また、NHibernate プロファイラーを使用して、生成された sql ステートメントを分析しました。SQL Server Studio で sql ステートメントを個別に実行すると、1 秒未満しかかかりませんでした。

ほとんどの時間は、式の作成または sql ステートメントへの変換に費やされたようです。

この問題を回避する方法はありますか?

NHibernate の使用経験はあまりありません。誰かがこれにいくつかの光を当てることができれば、それは素晴らしいことです.

時間を割いて読んでいただきありがとうございます。

4

1 に答える 1

1

返された行数よりも重要なのは、テーブル内の行の総数です。

SQL Server Studio で sql ステートメントを個別に実行すると、1 秒未満しかかかりませんでした。

この方法でテストすると、誤解を招く可能性があります。クエリの 2 回目の実行では、以前にコンパイルされた SQL ステートメント、以前に計算されたクエリ実行プラン、以前にいっぱいになったデータ バッファーを利用できます。また、SQL で直接すべてのパラメーター名をその値に置き換えてテストすると、別の実行計画につながります。

私が最初に行うことは、インデックスの間違った使用法をチェックすることです（関連するインデックスの欠落または古い統計）

これは、推定クエリ実行プランを調べることで実行できます。統計については、https ://dba.stackexchange.com/q/12004 をご覧ください。

これも役に立つと思います: Nhibernate から実行されたクエリは遅いですが、ADO.NET からは高速です

ややクリーンアップされた環境で SQL-SERVER ステートメントをテストするには、以下を参照してください。

各クエリに対してこのバッチを実行して、実行時間と統計結果を比較します (本番環境では実行しないでください)。

DBCC FREEPROCCACHE
GO

CHECKPOINT 
GO

DBCC DROPCLEANBUFFERS 
GO

SET STATISTICS IO ON
GO

SET STATISTICS TIME ON
GO

-- your query here
GO

SET STATISTICS TIME OFF
GO

SET STATISTICS IO OFF
GO
于 2013-03-21T13:41:05.410 に答える