The default field for query terms if no prefix field
is specified. Defaults to the index.query.default_field index
settings, which in turn defaults to _all.

default_operator

The default operator used if no explicit operator
is specified. For example, with a default operator of OR, the query
capital of Hungary is translated to capital OR of OR Hungary, and
with default operator of AND, the same query is translated to
capital AND of AND Hungary. The default value is OR.

analyzer

The analyzer name used to analyze the query string.

allow_leading_wildcard

When set, * or ? are allowed as the first
character. Defaults to true.

lowercase_expanded_terms

Whether terms of wildcard, prefix, fuzzy,
and range queries are to be automatically lower-cased or not (since they
are not analyzed). Default it true.

enable_position_increments

Set to true to enable position
increments in result queries. Defaults to true.

fuzzy_max_expansions

Controls the number of terms fuzzy queries will
expand to. Defaults to 50

fuzziness

Set the fuzziness for fuzzy queries. Defaults
to AUTO. See Fuzzinessedit for allowed settings.

fuzzy_prefix_length

Set the prefix length for fuzzy queries. Default
is 0.

phrase_slop

Sets the default slop for phrases. If zero, then exact
phrase matches are required. Default value is 0.

boost

Sets the boost value of the query. Defaults to 1.0.

analyze_wildcard

By default, wildcards terms in a query string are
not analyzed. By setting this value to true, a best effort will be
made to analyze those as well.

auto_generate_phrase_queries

Defaults to false.

max_determinized_states

Limit on how many automaton states regexp
queries are allowed to create. This protects against too-difficult
(e.g. exponentially hard) regexps. Defaults to 10000.

minimum_should_match

A value controlling how many "should" clauses
in the resulting boolean query should match. It can be an absolute value
(2), a percentage (30%) or a
combination of both.

lenient

If set to true will cause format based failures (like
providing text to a numeric field) to be ignored.

locale

Locale that should be used for string conversions.
Defaults to ROOT.

time_zone

Time Zone to be applied to any range query related to dates. See also
JODA timezone.

When a multi term query is being generated, one can control how it gets
rewritten using the
rewrite
parameter.

Since several queries are generated from the individual search terms,
combining them can be automatically done using either a dis_max query or a
simple bool query. For example (the name is boosted by 5 using ^5
notation):

Simple wildcard can also be used to search "within" specific inner
elements of the document. For example, if we have a city object with
several fields (or inner object with fields) in it, we can automatically
search on all "city" fields:

The query string is parsed into a series of terms and operators. A
term can be a single word — quick or brown — or a phrase, surrounded by
double quotes — "quick brown" — which searches for all the words in the
phrase, in the same order.

Operators allow you to customize the search — the available options are
explained below.

Wildcard searches can be run on individual terms, using ? to replace
a single character, and * to replace zero or more characters:

qu?ck bro*

Be aware that wildcard queries can use an enormous amount of memory and
perform very badly — just think how many terms need to be queried to
match the query string "a* b* c*".

Allowing a wildcard at the beginning of a word (eg "*ing") is particularly
heavy, because all terms in the index need to be examined, just in case
they match. Leading wildcards can be disabled by setting
allow_leading_wildcard to false.

Wildcarded terms are not analyzed by default — they are lowercased
(lowercase_expanded_terms defaults to true) but no further analysis
is done, mainly because it is impossible to accurately analyze a word that
is missing some of its letters. However, by setting analyze_wildcard to
true, an attempt will be made to analyze wildcarded words before searching
the term list for matching terms.

We can search for terms that are
similar to, but not exactly like our search terms, using the “fuzzy”
operator:

quikc~ brwn~ foks~

This uses the
Damerau-Levenshtein distance
to find all terms with a maximum of
two changes, where a change is the insertion, deletion
or substitution of a single character, or transposition of two adjacent
characters.

The default edit distance is 2, but an edit distance of 1 should be
sufficient to catch 80% of all human misspellings. It can be specified as:

While a phrase query (eg "john smith") expects all of the terms in exactly
the same order, a proximity query allows the specified words to be further
apart or in a different order. In the same way that fuzzy queries can
specify a maximum edit distance for characters in a word, a proximity search
allows us to specify a maximum edit distance of words in a phrase:

"fox quick"~5

The closer the text in a field is to the original order specified in the
query string, the more relevant that document is considered to be. When
compared to the above example query, the phrase "quick fox" would be
considered more relevant than "quick brown fox".

By default, all terms are optional, as long as one term matches. A search
for foo bar baz will find any document that contains one or more of
foo or bar or baz. We have already discussed the default_operator
above which allows you to force all terms to be required, but there are
also boolean operators which can be used in the query string itself
to provide more control.

The preferred operators are + (this term must be present) and -
(this term must not be present). All other terms are optional.
For example, this query:

quick brown +fox -news

states that:

fox must be present

news must not be present

quick and brown are optional — their presence increases the relevance

The familiar operators AND, OR and NOT (also written &&, || and !)
are also supported. However, the effects of these operators can be more
complicated than is obvious at first glance. NOT takes precedence over
AND, which takes precedence over OR. While the + and - only affect
the term to the right of the operator, AND and OR can affect the terms to
the left and right.

Rewriting the above query using AND, OR and NOT demonstrates the
complexity:

quick OR brown AND fox AND NOT news

This is incorrect, because brown is now a required term.

(quick OR brown) AND fox AND NOT news

This is incorrect because at least one of quick or brown is now required
and the search for those terms would be scored differently from the original
query.

((quick AND fox) OR (brown AND fox) OR fox) AND NOT news

This form now replicates the logic from the original query correctly, but
the relevance scoring bares little resemblance to the original.

In contrast, the same query rewritten using the match query
would look like this:

If you need to use any of the characters which function as operators in your
query itself (and not as operators), then you should escape them with
a leading backslash. For instance, to search for (1+1)=2, you would
need to write your query as \(1\+1\)\=2.

Failing to escape these special characters correctly could lead to a syntax
error which prevents your query from running.

Watch this space

A space may also be a reserved character. For instance, if you have a
synonym list which converts "wi fi" to "wifi", a query_string search
for "wi fi" would fail. The query string parser would interpret your
query as a search for "wi OR fi", while the token stored in your
index is actually "wifi". Escaping the space will protect it from
being touched by the query string parser: "wi\ fi".