Elasticsearch query_string查询报错及返回结果异常问题
测试相关基础信息
以下为测试使用的字典数据:
abc = [ {'id':"1", 'name': 'cristiano ronaldo', 'description': 'portugal@fifa.com'}, {'id':"2", 'name': 'lionel messi', 'description': 'argentina@fifa.com'}, {'id':"3", 'name': 'Lionel Jr', 'description': 'brazil@fifa.com'} ]
写入Elasticsearch players 索引的执行代码:
for i in abc: es.index(index="players", body=i, id=i['id'])
测试用查询DSL:
resp = es.search(index="players",body={ "query": { "query_string": { "fields": ["id^12","description^2", "name^2"], "query": "brazil@fifa.com" } }}) resp
问题记录
- 问题1:查询字段配置为
"fields": ["id^12","description^2", "name^2"]时,返回报错:RequestError: RequestError(400, 'search_phase_execution_exception', 'failed to create query: For input string: "brazil@fifa.com"。已通过将原long类型的id字段修改为带keyword子字段的text类型解决,修改后的索引映射如下:
{ "players": { "mappings": { "properties": { "description": { "type": "text", "fields": { "keyword": {"type": "keyword", "ignore_above": 256} } }, "id": { "type": "text", "fields": { "keyword": {"type": "keyword", "ignore_above": 256} } }, "name": { "type": "text", "fields": { "keyword": {"type": "keyword", "ignore_above": 256} } } } } } }
- 问题2:查询字段配置为
["description^2", "name^2"]时,预期仅返回description包含brazil@fifa.com的1条文档,实际返回了索引内全部3条文档。
问题2原因说明
该问题由两个默认机制共同导致:
- Elasticsearch默认的standard分词器会将
@、.这类特殊符号作为分词分隔符,传入的查询词brazil@fifa.com会被拆分为brazil、fifa、com多个独立词元。 query_string查询默认使用OR逻辑匹配分词后的词元,只要对应字段包含任意一个词元就会判定为命中。索引内3条文档的description字段都包含fifa、com这两个词元,因此全部被返回。
解决方法
根据实际业务的匹配需求选择对应方案即可:
- 方案1:需要完整精确匹配整个邮箱字符串,直接查询字段的keyword子字段(keyword类型不分词,做完整值匹配),将fields配置修改为
["description.keyword^2", "name.keyword^2"],此时只会返回description字段值完全等于brazil@fifa.com的目标文档。 - 方案2:需要做全文检索但要求所有分词后的词元都命中,给
query_string增加default_operator: "AND"配置,修改后的查询代码如下:
resp = es.search(index="players",body={ "query": { "query_string": { "fields": ["description^2", "name^2"], "query": "brazil@fifa.com", "default_operator": "AND" } }})
该配置下需要字段同时包含brazil、fifa、com所有词元才会命中,也只会返回id为3的目标文档。
- 方案3:如果不需要使用
query_string的高级查询语法(比如通配符、多逻辑符拼接查询),直接替换为match查询配合AND逻辑,或者用term查询匹配keyword子字段,查询性能更稳定,也不容易出现非预期的匹配结果。
内容的提问来源于stack exchange,提问作者sim
相关产品推荐
相关产品推荐

