ドキュメントを見て、どのドキュメントがヒットして返されているかを確認する必要があります。
もしフィールドのないドキュメントがあれば、それが8つのドキュメントになるかもしれません。
もし'Phi'という値を持つドキュメントが3つあれば、それが3つのドキュメントになります。
一度ポジティブな条件があると、否定条件でそのドキュメントを除外することしかできませんので、それが3つのドキュメントになります。

しかし、どのドキュメントIDが返されているか、どのフィールドがそれらに対して使用されているかを見て、クエリの結果を逆解析することが重要です。

Luceneクエリの構文のちょっとした特異性にぶつかっていますね。その特異性は、純粋に否定的なクエリを実際には実行できないことです。

あなたの中間のクエリが動作するのは、Solrがその実行不可能なクエリを検出して裏側で修正できるからです。もし直接Luceneにそのクエリを提供した場合、おそらく動作しないでしょう。三番目のクエリはSolrにとって問題を検出するのが複雑すぎます。

そのような構文を使用すると、Luceneに対してドキュメントを結果セットから差し引くことを指示しています。つまり、あなたの三番目のクエリが平易な言葉で解析されるとすれば：

「このフィールドで特定の文字列に一致するすべてのドキュメントを始め、このフィールドが存在するすべてのドキュメントを差し引く。」そのため、最初に3つのドキュメントが始まります。なぜなら、クエリの第二節は差し引きですから。

また、ワイルドカードクエリを使用することで極端な非効率性も生じています。レンジクエリの方がはるかに効率的です。

あなたができる限り効率よく望む結果を得るために送信すべきクエリは次の通りです（引用符のエスケープは貼り付けたものから除外しています）：

prodAllGeneric_txt_sort:"Phi; " OR (*:* -prodAllGeneric_txt_sort:[* TO *])

最初の節には不要な括弧が含まれていないため、それらはこの構文では不要です。もし実際のクエリがもっと複雑な場合は、再度括弧を追加する必要があるかもしれません。

ありがとうございます。
Shawn

Shawn さん、Timさん、
以下の行が私の問題を解決しました。

prodAllGeneric_txt_sort:"Phi; " OR (: -prodAllGeneric_txt_sort:[* TO *])

さらに、説明が非常に役立ちました。
ありがとうございます。
Zhiqing