メールのクロス投稿はしないでください。Users か Dev のどちらか一方を選んでください。

また、このメールのバリエーションを受け取るのはこれで3回目ですので、これ以上送るのはやめてください。
誰かが必ず返信します。

– Houston

Solrで frange を含む OR 条件の fq フィルターを使用すると、クエリ時間が大幅に増加することに悩まされています。他の構成のクエリと比べてレスポンス時間が著しく長くなります。

クエリ例
fq={!cache=false tag=prm}field:value OR {!frange l=1 u=1 v=$funcQuery}

まず最初に理解しておいてほしいのは、{!...} の構文は 接頭辞ベース だということです。つまり、{!cache=false tag=prm} は "fq" パラメータ 全体 に適用されます ― 単に "field:value" のブール節だけではありません。
あなたのクエリの分解の仕方を見ると、そうは思っていないように見えたので、ここを明確にしておきます。

観察結果

1. frange の部分のみ使用するとクエリが速い（20ms）

ここで重要なのは細かい点です ― 「frange部分だけを使ったとき速い」と書いていますが、それを どのように 単体で使ったのかが明確ではありません。

もし「fq={!frange l=1 u=1 v=$funcQuery}」のように単独で使用して速かったという意味であれば、それは 初回の実行は遅く、その後 filterCache にキャッシュされて高速になる からだと考えられます。

質問

1. なぜ frange と OR を組み合わせるとクエリ時間が大幅に増えるのか？

frange クエリは、インデックス内の すべてのドキュメント を走査して関数の値を計算し、その値が範囲内かどうかをチェックします。

一般的に Lucene/Solr は、2つの節からなるブール "AND" クエリを実行する際、検索器（searcher）が各節に対して「他の節の一致ポイントにスキップ」するよう指示できます。

したがって、たとえば X:Y AND {!frange...} のように X:Y がインデックスのごく一部にしかマッチしない場合、frange 関数の計算はインデックス全体ではなく、X:Y に一致するドキュメントに対してだけ行えば済むのです。

しかし、X:Y OR {!frange...} のようなクエリでは、結局のところ すべてのドキュメント に対して関数を計算する必要があります。そして、それに加えて {!cache=false} を使っていることで（※これは fq 全体に適用される）、キャッシュの恩恵すらなくなってしまいます。

1. パフォーマンス改善のための最適化や代替のクエリ構造はありますか？

Solr には少し変わった構文として filter() というものがあり、これは特定のブール節を スコア計算をしないキャッシュ対象のフィルター として指定するために使えます。
この構文を使えば、別のブールクエリ内でも filterCache のヒットとして再利用されます：

fq=X:Y OR filter({!frange...})
fq=X:Z OR filter({!frange...})  // frange の結果は filterCache にヒット

– Hoss
http://www.lucidworks.com/

理想的には、ユーザーが JIRA チケットを作成した後、このスレッドで共有されるのが望ましいです。こちらです：
https://issues.apache.org/jira/browse/SOLR-17699
（9.9 向けの修正）

良い返信ですね、Hoss。特に「filter」構文の裏技を共有してくれたのは有益だと思います。