如何在Elasticsearch中针对content字段实现大小写敏感搜索？

嗨，我来帮你搞定这个问题～ Elasticsearch默认确实是大小写不敏感的，这是因为它默认的文本分析器会把所有输入的文本转成小写后再索引，所以常规搜索会忽略大小写。要在content字段实现大小写敏感搜索，有两种常用的靠谱方法，我给你详细拆解下：

方法一：给content字段添加keyword子字段 #

keyword类型的字段默认不会做分词和大小写转换，会完整保留原始文本的格式，非常适合做精确的大小写敏感匹配。

操作步骤： #

1. 如果是新建索引，你可以在mapping里这样定义：

PUT /rss_news
{
  "mappings": {
    "properties": {
      "content": {
        "type": "text", // 保留原有的text类型用于常规大小写不敏感搜索
        "fields": {
          "raw": {
            "type": "keyword" // 添加keyword子字段用于大小写敏感搜索
          }
        }
      },
      "title": {"type": "text"},
      "guid": {"type": "keyword"},
      "link": {"type": "keyword"}
    }
  }
}

2. 如果是已经存在的索引，你可以通过更新mapping来添加这个子字段（不会影响现有数据，但需要重新索引才能让旧数据生效）：

PUT /rss_news/_mapping
{
  "properties": {
    "content": {
      "fields": {
        "raw": {
          "type": "keyword"
        }
      }
    }
  }
}

然后用_reindex API把旧数据重新索引一遍，让子字段生效。

3. 查询的时候，直接使用content.raw字段进行搜索：

GET /rss_news/_search
{
  "query": {
    "match": {
      "content.raw": "YourCaseSensitiveText" // 这里输入你要精确匹配的带大小写的文本
    }
  }
}

方法二：自定义大小写敏感的分析器 #

如果你需要的是全文本范围内的大小写敏感匹配（比如在content里搜索包含“Elasticsearch”的内容，而排除“elasticsearch”），那可以自定义一个不做小写转换的分析器。

操作步骤： #

1. 新建索引时定义自定义分析器和对应的mapping：

PUT /rss_news
{
  "settings": {
    "analysis": {
      "analyzer": {
        "case_sensitive_analyzer": {
          "tokenizer": "standard", // 使用标准分词器
          "filter": ["stop"] // 只保留停用词过滤器，去掉默认的lowercase过滤器
        }
      }
    }
  },
  "mappings": {
    "properties": {
      "content": {
        "type": "text",
        "analyzer": "case_sensitive_analyzer", // 索引时用自定义分析器
        "search_analyzer": "case_sensitive_analyzer" // 查询时也用同一个分析器
      },
      "title": {"type": "text"},
      "guid": {"type": "keyword"},
      "link": {"type": "keyword"}
    }
  }
}

2. 如果是已存在的索引，这个方法需要你重新创建索引并导入数据，因为字段的分析器无法直接修改已存在的字段。

3. 查询时直接使用content字段即可，此时搜索会严格区分大小写：

GET /rss_news/_search
{
  "query": {
    "match": {
      "content": "YourCaseSensitiveText"
    }
  }
}

小提醒 #

如果只是偶尔需要一次大小写敏感搜索，也可以用term查询（前提是字段有keyword类型的映射），但上面两种方法是更长期、更灵活的解决方案。

备注：内容来源于stack exchange，提问作者msp12