> 9.2 起这两种索引模式下 `text` 字段的 norms 默认关闭。官方 details 里有一句很关键：**由于不支持从禁用状态启用，用户将无法在这些索引上开启 norms**。这意味着日志和时序场景的 `text` 字段，打分会退化成恒定值。

## **说明**

本文描述问题及解决方法同样适用于 [腾讯云 Elasticsearch Service（ES）](https://cloud.tencent.com/document/product/845)。

## 官方条目

9.2 的 changelog 标为 breaking（[9.2.0.yml 第 363–373 行 @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.2.0.yml#L363-L373)），`area: Mapping`。

details 说得很完整：

> This changes the default behavior for norms on `text` fields in logsdb and tsdb indices. Prior to this change, norms were enabled by default, with the option to disable them via manual configurations. After this change, norms will be disabled by default. Note, because we dont support enabling norms from a disabled state, users will not be able to enable norms on `text` fields in logsdb and tsdb indices.

impact 一句：

> Text fields will no longer be normalized by default in LogsDB and TSDB indicies.

拆开看，三层意思：

* **以前**：norms 默认**开启**，可以手动关；
* **现在**：默认**关闭**；
* **而且**：因为不支持从禁用状态启用，**以后也开不了**。

第三层是这条改动里最重的一句，很多人会漏掉。

## norms 是什么

norms 是 Lucene 存的一套**归一化因子**，用于相关性打分。最典型的作用是**字段长度归一**：同样的词，出现在短字段里比出现在长字段里更"重要"。

举个例子：搜索 `error`——

* 一个 `message` 字段只有 5 个词，其中一个是 `error`；
* 另一个 `message` 字段有 500 个词，其中一个也是 `error`；

**第一个应该得分更高**（因为它更集中）。这个"更集中"的判断就靠 norms 提供的长度信息。

关掉 norms 之后，长度信息没有了，**这种区分就做不到了**。

## 关掉之后会发生什么

可以从一个已有的字段类型看清楚——`match-only-text`。它的文档说明（[match-only-text.md @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/elasticsearch/mapping-reference/match-only-text.md)）：

> A variant of `text` that trades scoring and efficiency of positional queries for space efficiency. This field effectively stores data the same way as a `text` field that only indexes documents (`index_options: docs`) and disables norms (`norms: false`). ... **All queries return constant scores that are equal to 1.0.**

最后一句是关键：**禁用 norms 之后，所有查询返回恒定分数 1.0**。

（严格说 `match-only-text` 还改了 `index_options`，不完全等同于只关 norms。但"禁用 norms → 分数恒定"这个关联是清楚的。）

也就是说，在 LogsDB / TSDB 索引上：

* `match` 查询**仍然能匹配**（召回不受影响）；
* 但**所有匹配返回的分数都一样**，无法按相关度排序。

这一点我觉得是最该讲清楚的：**它不是"打分变差了一点"，是"打分没有区分度了"**。

## 对日志场景影响大吗

我的判断是：**大多数日志场景影响很小**。

理由是日志检索的用法通常是：

* 按时间排序（`SORT @timestamp DESC`）；
* 按条件过滤（`WHERE level == "error"`）；
* 聚合统计（`STATS count BY ...`）。

这三种**都不依赖相关度打分**。分数恒定不影响它们。

**会受影响的是**：在日志上做**相关性排序**的场景。比如：

* 搜索日志内容并按"最相关"排序；
* 用 `SORT _score DESC`（我在 [ES|QL 的 SCORE()](./es9-101-esql-score-function.md) 里写过 `_score` 的用法）。

这类用法在日志场景不常见，但确实存在——比如"从海量日志里找出最像某类故障的那些"。

**如果有这类需求，这条改动会让它失效**。而且按官方说法，**开不回来**。

## "开不回来"意味着什么

这是我觉得最需要提醒的一点。

官方说 `we dont support enabling norms from a disabled state`——**norms 一旦禁用就无法再启用**。

这不是"默认值改了你可以改回去"，而是**这个索引模式下这条路被封了**。

后果是：**如果你的 logsdb 索引需要 norms，只能不用 logsdb 模式**。也就是说——

* 要么接受打分退化；
* 要么把索引改成 `standard` 模式（代价是失去 logsdb 的存储优化）；
* 要么把需要打分的字段放到另一个 standard 索引里。

这是个**二选一**的取舍，不是可调的开关。我在 [_resolve/index 返回模式](./es9-95-resolve-index-mode.md) 里写过索引模式怎么查、各模式适合什么，这次的结论可以补进去：**需要相关性排序的 text 字段，不要放在 LogsDB / TSDB 索引里**。

## 为什么官方要这么改

按我的理解（官方没在 details 里解释动机，这段是我的推断）：

**norms 占空间。** 每个字段、每个文档都要存一个归一化因子。日志和时序数据的特点是——

* 文档数量极大；
* 每个文档都要存 norms；
* 而这些场景**几乎不用相关性打分**。

所以 norms 在这两种模式下是**纯成本、无收益**。禁掉能省不少空间，而代价（失去打分区分度）在这些场景里几乎没人付。

我判断这个取舍是对的，**日志索引本来就不该按相关度排序**。但对少数有这类需求的场景，这就是个硬约束了——**这也是为什么它被评为 breaking**。

## 怎么确认自己有没有受影响

**一，看索引是不是 logsdb / tsdb 模式。** 这是前提。用我在 [_resolve/index 返回模式](./es9-95-resolve-index-mode.md) 里写过的方式：

```sh
curl -s 'localhost:9200/_resolve/index/*?mode=logsdb,time_series&pretty'
```

能列出所有这两种模式的索引。

**二，看这些索引里有没有 `text` 字段。** 查 mapping：

```sh
curl -s 'localhost:9200/my-logs/_mapping?pretty' | grep -B2 '"type": *"text"'
```

**三，确认有没有按分数排序的用法。**

```sh
grep -rn "_score" --include=*.esql --include=*.py --include=*.json . | grep -i "sort"
```

三条都命中才需要处理。

## 受影响怎么办

按我前面说的三条路，我的排序是：

**首选：接受它。** 如果你们的日志查询本来就是按时间排序、按条件过滤，那分数恒定没有实际影响。这种情况下什么都不用做——**确认"我们没有按分数排序"本身就是个有效结论**，不用为了消除警告而改配置。

**次选：把需要打分的字段分离。** 如果只有少数字段需要相关度排序，考虑把这些字段放到一个 `standard` 模式的索引里。这样主体数据仍享受 logsdb 的存储优化，代价是多一份存储和一次写入。适合"大部分日志只查时间线、少量场景要搜内容"的情况。

**最后：改索引模式。** 整个索引改成 `standard`。代价是失去存储优化，**我不建议为打分做这个交换**——除非打分是核心需求。

这里的判断是：**大多数团队落在第一种**，什么都不用做。这条 breaking 真正咬到的是"在日志上做相关性搜索"的小众场景——但正因为小众，一旦命中就会觉得莫名其妙，所以值得知道它的存在。

## 一个容易混淆的点：norms 和 analyzer 没关系

我在写这篇时想到一个可能的误解，值得说清楚：**关掉 norms 不影响分词**。

`text` 字段的处理有两步：

* **分析（analysis）**：把文本切成词，由 analyzer 负责；
* **打分（scoring）**：匹配上了给多少分，norms 参与这一步。

关掉 norms **只影响第二步**。分词照常进行，`match` 照常匹配，只是分数不再有区分度。

所以如果你遇到"某个词搜不到了"，**那不是 norms 的问题**——那是 analyzer 或者字段映射的问题，排查方向完全不同。norms 只会导致"搜得到但排不准"。

我提这一点是因为这两个概念在排查时容易被混在一起。区分清楚能省掉一轮无效排查：**召回问题查 analyzer，排序问题才查 norms**。

## 怎么验证分数是不是真的恒定了

如果想知道自己的索引是不是真的没有分数区分度，直接跑一次看：

```esql
FROM my-logs METADATA _score
| WHERE match(message, "error")
| KEEP _score, message
| SORT _score DESC
| LIMIT 10
```

看返回的 `_score` 是不是都一样。

**注意要加 `METADATA _score`**（我在 [ES|QL 的 SCORE()](./es9-101-esql-score-function.md) 里写过，不加就拿不到这一列）。

如果十条结果的分数完全相同，说明 norms 确实没生效——这是符合预期的，不是故障。

反过来，如果你**需要**分数区分度，这个查询结果就是你评估影响范围的依据：**看看按分数排出来的顺序是不是你想要的**。分数恒定意味着顺序基本是任意的（实际上可能按文档 ID 或其它稳定顺序）。

## 和 indexed 的 logsdb 默认开启连起来看

9.0 有条改动是"匹配 `logs-*-*` 的数据流默认走 LogsDB"（我写过，见 [logs-*-* 默认走 LogsDB](./es9-61-logsdb-default-for-logs-streams.md)），9.2 这条是"logsdb 下 norms 默认关闭"。

两条连起来的效果是：**新建的日志数据流，其 text 字段默认不带 norms**。

这是个连锁效应——你没主动选 logsdb（是默认给你的），也就连带接受了 norms 被禁用。

我提这一点的意思是：**如果你发现日志索引的打分不对劲，别只查查询写法**，先看索引是什么模式。模式决定了 norms，norms 决定了有没有分数区分度。这条因果链不查索引是看不出来的。

## 写在最后

这条 breaking 的技术内容不难，但它有个我特别想强调的属性：**默认行为变了，而且不可逆**。

多数 breaking 是"行为变了，可以改回去"或者"老写法被拒绝，换成新写法"。这条是**能力消失了**——在 logsdb / tsdb 索引上，norms 这条路不再存在。

**一，影响的是"打分区分度"，不是召回。** `match` 照常匹配，只是所有结果分数相同。按时间排序、按条件过滤、聚合统计都不受影响。

**二，它不可逆。** 官方明说不支持从禁用状态启用。需要 norms 的话只能不用这两种索引模式。

**三，大多数日志场景不用处理。** 只有"在日志上按相关度排序"的场景才需要考虑。判据就是你的查询里有没有 `SORT _score`。

最后补一句我写这篇时的感受：这类改动在 changelog 里很容易被跳过——一行 summary，讲的还是 norms 这种有点偏门的细节。但对依赖相关性排序的少数场景，它是硬约束。**读 breaking changes 时，"不可逆"这三个字比"默认值变了"更值得停下来看一眼。**

## 参考

- [changelog 9.2.0：Don't enable norms for fields of type text when the index mode is LogsDB or TSDB（第 363–373 行）@ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/release-notes/changelog-bundles/9.2.0.yml#L363-L373)
- [`match-only-text.md`：禁用 norms 后"所有查询返回恒定分数 1.0"的对照说明 @ v9.4.2](https://github.com/elastic/elasticsearch/blob/v9.4.2/docs/reference/elasticsearch/mapping-reference/match-only-text.md)

> 本文对照 Elasticsearch `v9.4.2` 标签的 changelog 与官方文档核对，引文逐字取自原文。关于"官方为何禁用 norms"的动机说明是我的推断，官方 details 未解释，已在正文标注。`match-only-text` 还额外修改了 `index_options`，不完全等同于仅禁用 norms，文中已说明该对照的适用范围。撰写时未启动集群、未运行测试。


9.2 起这两种索引模式下 text 字段的 norms 默认关闭。官方 details 里有一句很关键：由于不支持从禁用状态启用，用户将无法在这些索引上开启 norms。这意味着日志和时序场景的 text 字段，打分会退化成恒定值。

ES 的 LogsDB 和 TSDB 索引里 `text` 字段不再有 norms 了，而且开不回来

9.2 起这两种索引模式下 text 字段的 norms 默认关闭。

官方产研

云计算

后端

大数据

9.2起LogsDB和TSDB索引的text字段默认禁用norms，且不可逆。影响是相关性打分退化为恒定分数1.0，但召回不受影响。多数日志场景（按时间排序、过滤、聚合）无需处理，仅依赖`SORT _score`的相关性排序场景受影响，需改用standard索引或分离字段。

存储优化

代码解释

数据流

JSON

2026上云采购 | AI焕新·智启新局

bigdata-class

日志服务CLS新用户首单0.8折起！


文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

ES 的 LogsDB 和 TSDB 索引里 `text` 字段不再有 norms 了，而且开不回来-腾讯云开发者社区-腾讯云

ES 的 LogsDB 和 TSDB 索引里 `text` 字段不再有 norms 了，而且开不回来

ES 的 LogsDB 和 TSDB 索引里 `text` 字段不再有 norms 了，而且开不回来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐