第六章：mapping 不是可有可无 —— 它决定你的雷达能不能正常工作

mapping 的本质不是“字段声明”这么简单，而是：

这份数据进入雷达站后，到底按什么物理规则建索引。

例如：

http

PUT /city_products
{
  "mappings": {
    "properties": {
      "title": { "type": "text" },
      "brand": { "type": "keyword" },
      "price": { "type": "integer" },
      "created_at": { "type": "date" }
    }
  }
}

它决定了这些事：

title 会走全文检索逻辑
brand 更适合 term 查询、排序、聚合
price 能做数值范围过滤
created_at 能做时间范围过滤和日期直方图

很多人一开始靠动态映射也能跑起来，但生产上常见问题恰恰来自“跑起来了却没建对”。

例如：

本来要精确匹配的字段被当成了 text
本来要全文搜的字段却只做成了 keyword
本来要聚合的字段没有合适的可聚合形态
一个字段今天写字符串、明天写数字，最后整个索引结构被污染

非常重要的一条经验是：

关系库里字段类型错了，常常还能 ALTER 修一修；Elasticsearch 里核心字段类型一旦定错，往往意味着新建索引再重建。