WARNING: Version 2.3 of Elasticsearch has passed its EOL date.
This documentation is no longer being maintained and may be removed. If you are running this version, we strongly advise you to upgrade. For the latest information, see the current release documentation.
Query String Query
editQuery String Query
editA query that uses a query parser in order to parse its content. Here is an example:
{ "query_string" : { "default_field" : "content", "query" : "this AND that OR thus" } }
The query_string
top level parameters include:
Parameter | Description |
---|---|
|
The actual query to be parsed. See Query string syntax. |
|
The default field for query terms if no prefix field
is specified. Defaults to the |
|
The default operator used if no explicit operator
is specified. For example, with a default operator of |
|
The analyzer name used to analyze the query string. |
|
When set, |
|
Whether terms of wildcard, prefix, fuzzy,
and range queries are to be automatically lower-cased or not (since they
are not analyzed). Defaults to |
|
Set to |
|
Controls the number of terms fuzzy queries will
expand to. Defaults to |
|
Set the fuzziness for fuzzy queries. Defaults
to |
|
Set the prefix length for fuzzy queries. Default
is |
|
Sets the default slop for phrases. If zero, then exact
phrase matches are required. Default value is |
|
Sets the boost value of the query. Defaults to |
|
By default, wildcards terms in a query string are
not analyzed. By setting this value to |
|
Defaults to |
|
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. |
|
A value controlling how many "should" clauses
in the resulting boolean query should match. It can be an absolute value
( |
|
If set to |
|
Locale that should be used for string conversions.
Defaults to |
|
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.
Default Field
editWhen not explicitly specifying the field to search on in the query
string syntax, the index.query.default_field
will be used to derive
which field to search on. It defaults to _all
field.
So, if _all
field is disabled, it might make sense to change it to set
a different default field.
Multi Field
editThe query_string
query can also run against multiple fields. Fields can be
provided via the "fields"
parameter (example below).
The idea of running the query_string
query against multiple fields is to
expand each query term to an OR clause like this:
field1:query_term OR field2:query_term | ...
For example, the following query
{ "query_string" : { "fields" : ["content", "name"], "query" : "this AND that" } }
matches the same words as
{ "query_string": { "query": "(content:this OR name:this) AND (content:that OR name:that)" } }
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):
{ "query_string" : { "fields" : ["content", "name^5"], "query" : "this AND that OR thus", "use_dis_max" : true } }
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:
{ "query_string" : { "fields" : ["city.*"], "query" : "this AND that OR thus", "use_dis_max" : true } }
Another option is to provide the wildcard fields search in the query
string itself (properly escaping the *
sign), for example:
city.\*:something
.
When running the query_string
query against multiple fields, the
following additional parameters are allowed:
Parameter | Description |
---|---|
|
Should the queries be combined using |
|
When using |
The fields parameter can also include pattern based field names, allowing to automatically expand to the relevant fields (dynamically introduced fields included). For example:
{ "query_string" : { "fields" : ["content", "name.*^5"], "query" : "this AND that OR thus", "use_dis_max" : true } }
Query string syntax
editThe query string “mini-language” is used by the
Query String Query and by the
q
query string parameter in the search
API.
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.
Field names
editAs mentioned in Query String Query, the default_field
is searched for the
search terms, but it is possible to specify other fields in the query syntax:
-
where the
status
field containsactive
status:active
-
where the
title
field containsquick
orbrown
. If you omit the OR operator the default operator will be usedtitle:(quick OR brown) title:(quick brown)
-
where the
author
field contains the exact phrase"john smith"
author:"John Smith"
-
where any of the fields
book.title
,book.content
orbook.date
containsquick
orbrown
(note how we need to escape the*
with a backslash):book.\*:(quick brown)
-
where the field
title
has no value (or is missing):_missing_:title
-
where the field
title
has any non-null value:_exists_:title
Wildcards
editWildcard 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.
Regular expressions
editRegular expression patterns can be embedded in the query string by
wrapping them in forward-slashes ("/"
):
name:/joh?n(ath[oa]n)/
The supported regular expression syntax is explained in Regular expression syntax.
The allow_leading_wildcard
parameter does not have any control over
regular expressions. A query string such as the following would force
Elasticsearch to visit every term in the index:
/.*n/
Use with caution!
Fuzziness
editWe 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:
quikc~1
Proximity searches
editWhile 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"
.
Ranges
editRanges can be specified for date, numeric or string fields. Inclusive ranges
are specified with square brackets [min TO max]
and exclusive ranges with
curly brackets {min TO max}
.
-
All days in 2012:
date:[2012-01-01 TO 2012-12-31]
-
Numbers 1..5
count:[1 TO 5]
-
Tags between
alpha
andomega
, excludingalpha
andomega
:tag:{alpha TO omega}
-
Numbers from 10 upwards
count:[10 TO *]
-
Dates before 2012
date:{* TO 2012-01-01}
Curly and square brackets can be combined:
-
Numbers from 1 up to but not including 5
count:[1 TO 5}
Ranges with one side unbounded can use the following syntax:
age:>10 age:>=10 age:<10 age:<=10
To combine an upper and lower bound with the simplified syntax, you
would need to join two clauses with an AND
operator:
age:(>=10 AND <20) age:(+>=10 +<20)
The parsing of ranges in query strings can be complex and error prone. It is
much more reliable to use an explicit range
query.
Boosting
editUse the boost operator ^
to make one term more relevant than another.
For instance, if we want to find all documents about foxes, but we are
especially interested in quick foxes:
quick^2 fox
The default boost
value is 1, but can be any positive floating point number.
Boosts between 0 and 1 reduce relevance.
Boosts can also be applied to phrases or to groups:
"john smith"^2 (foo bar)^4
Boolean operators
editBy 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
andbrown
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.
Grouping
editMultiple terms or clauses can be grouped together with parentheses, to form sub-queries:
(quick OR brown) AND fox
Groups can be used to target a particular field, or to boost the result of a sub-query:
status:(active OR pending) title:(full text search)^2
Reserved characters
editIf 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
.
The reserved characters are: + - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /
Failing to escape these special characters correctly could lead to a syntax error which prevents your query from running.
Empty Query
editIf the query string is empty or only contains whitespaces the query will yield an empty result set.