Elasticsearchのmatch系のクエリとterm系のクエリを、一覧にして比較してみました。

一覧にすることで、似たようなクエリで、あれ？　これどっちだったけというところで振り返りやすくなると思いました。

検索フィールド指定と検索語で、それぞれ単複どう指定できるか整理しました。
Elasticsearchでは、検索語の中のワードはデフォルトORらしいのですが、operatorに"and"を指定してクエリを投げるとANDになります。このORとANDを切り替えられるものを◯をつけました。（正確にいうと、公式リファレンスで、operatorプロパティが指定できると記載があったものに◯をつけたつもりですので、ひょっとするとコレ以外にもあるかもしれません。 ... が、みる限りORとANDの概念が存在しえるようなもの*1に◯がついているように見えるのでおそらくあっていると思います。）
実はクエリのシンタックス例は入れ込んでいないのですが、並べて比較することで、シンタックスのプロパティ階層を思い出しやすくなったと思います。もともとある程度クエリのシンタックスに慣れていることが前提ですが...

並べてみることで、これまであまり意識していなかったものに気づきました。

multi_matchのmost_fields版：複数フィールドにざっくり当たって欲しいが、bool-should記法は少しめんどくさい場合に便利
termsのlookupメカニズム：termsは複数の検索語を配列で指定できるが、その配列をある別のインデックスのドキュメントID=1のfollowersフィールドの値とする...というようなクエリ。アプリの変数を介する必要がない。

なお、上記に「Terms Set Query」が漏れていた。のでここに追記。

Terms Set Query

一言でいうと：検索語の指定はtermsに似ている。
検索対象フィールド：1つ（ただし、このフィルードは配列型になっている）
検索語：配列
検索結果：　検索語の配列で指定した配列のうち、minimum_should_match_fieldで指定した個数以上分の配列内の要素ヒットするようなドキュメント。

何か便利そうな気もするが、ここでは具体的なユースケースは思いつかなかった。

並べてみると分かるのですが...

並べてみると分かるのですが...というと少し強引ですが、

これだけクエリ種類があるといろいろ考えて欲張ってしまうのですが、検索サイトでは、次ぐらいの方針で良いのではと改めて感じました。

フリー検索BOXでは検索語はANDが多数派のような気がします。つまるところ自然語風に検索できますというところを特にウリにしない限り、フレーズ検索は使わない戦略を取っても良さそうです。
ORで検索したいようなシーンは、ディレクトリ検索（フリーの検索語ではなく、リンクやラベルを選択して選択状態にする）でカバーする使い分け方がすっきりしそうです。
term 系は、コード値や特定の属性にぴったりヒットさせる場合に使いますが、スコアリングを高めにして、term、termsで検索する。一方、wildcardやregexpやfuzzyは検索結果が0件や少ない場合に、「もしかしての」バリエーションとして追加で検索するという用途に寄せた方がシンプルになるかもしれません。要は、普通の検索はtermとtermsの使用にとどめる設計方針にしておき、個別の重要なユースケース対応が必要な場合は、「詳細検索」等としてワイルドカードが使える検索窓として別メニューにした方が良い（できればそのようなものは設けない方が良い）という気がしました。

図でまとめているクエリの一覧。