嘿，针对你在Elasticsearch 6.2里遇到的字符串长度范围查询问题，我给你两个实用的解决方案，顺便帮你理清之前踩的坑：

这是最靠谱且高效的方式，毕竟数值型字段的范围查询性能远优于脚本查询，还能避免分析器带来的干扰。

• 第一步：修改索引映射
  如果是新建索引，直接在映射里添加一个整数字段（比如text_length）来存储推文内容的长度；如果是已有索引，需要先关闭索引、更新映射再重新打开。示例如下：

  PUT /twitter_tweets
  {
    "mappings": {
      "doc": {
        "properties": {
          "tweet_content": {
            "type": "text"
          },
          "text_length": {
            "type": "integer"
          }
        }
      }
    }
  }
  

• 第二步：自动计算并存储长度
  你可以在业务代码里直接计算字符串长度后写入ES，也可以用ES的Ingest Pipeline让它自动处理：
  先创建一个计算长度的pipeline：

  PUT _ingest/pipeline/calculate_tweet_length
  {
    "description": "自动计算推文内容的字符长度",
    "processors": [
      {
        "script": {
          "lang": "painless",
          "source": "ctx.text_length = ctx.tweet_content.length();"
        }
      }
    ]
  }
  

  然后索引文档时指定这个pipeline：

  PUT /twitter_tweets/doc/1?pipeline=calculate_tweet_length
  {
    "tweet_content": "这里是从Twitter API获取的推文内容..."
  }
  

• 第三步：执行范围查询
  现在就可以直接对text_length做范围查询，比如找135-145字符的推文：

  GET /twitter_tweets/_search
  {
    "query": {
      "range": {
        "text_length": {
          "gte": 135,
          "lte": 145
        }
      }
    }
  }
  

你之前说Painless脚本没生效，大概率是写法出了问题。在ES 6.2里，要注意正确访问text字段的原始值，示例如下：

GET /twitter_tweets/_search
{
  "query": {
    "bool": {
      "filter": {
        "script": {
          "script": {
            "lang": "painless",
            "source": "doc['tweet_content'].value.length() >= 135 && doc['tweet_content'].value.length() <= 145"
          }
        }
      }
    }
  }
}

⚠️ 注意：脚本查询的性能不如数值字段，数据量较大时不建议用这个方案。

你提到的最小/最大为1的NGram方案，结果和实际长度不符是正常的——因为分析器会对字符串做预处理：比如默认会小写转换、过滤标点、移除停用词等，分词后的token数量根本不是原字符串的字符数。比如原推文是"Hello, World!"，经过标准分析器处理后会变成["hello", "world"]，token数量是2，但原字符串长度是13，完全对不上。NGram适合模糊匹配，不适合计算原始长度。

内容的提问来源于stack exchange，提问作者meh