搜索系列 · 第 06 篇——避坑汇总：经典生产问题

映射、分片与查询陷阱

一、导读

Elasticsearch 上手门槛不高，但调到生产级稳定并不轻松：查询变慢、内存飙升、集群红黄状态、写入被拒，往往不是单一语句问题，而是映射、分片、索引生命周期与集群水位共同作用的结果。本讲按「问题 → 危害 → 方案」逐项拆解。

二、映射陷阱

2.1 映射爆炸（Mapping Explosion）

ES 默认开启动态映射，文档可随意新增字段。当字段数失控增长（如日志里带大量不同键名），映射字段数量会指数膨胀，导致检索变慢、JVM 内存压力升高、启动与恢复时间拉长。ES 通过 index.mapping.total_fields.limit 默认限制单索引 1000 个字段，超限直接拒绝写入：

|--------------------------------------------------|
| # 命中字段数上限报错 |
| Limit of total fields $1000$ has been exceeded |
| # 解法：收敛动态映射，或按 key 落到 object/嵌套而非平铺字段 |
| "dynamic": "false", # 忽略未知字段 |
| "dynamic": "runtime", # 按需运行时字段 |

2.2 动态映射带来的类型误判

动态映射可能把数字当文本、把时间戳当字符串，导致后续聚合与范围查询失效。生产应显式定义 Mapping，或用 index template 统一字段类型与分词策略，而不是依赖动态推断。

2.3 滥用 nested / keyword 高基数

nested 查询开销高，能平铺就平铺；keyword 字段高基数（如每文档唯一值）会放大内存占用，应谨慎为唯一 ID 之类建 keyword，避免过度索引。

三、分片陷阱

3.1 主分片数创建后不可修改

主分片数（number_of_shards）在索引创建时指定后不可修改，改需重建索引（reindex）。因此索引规划必须前瞻：数据量、分片大小与节点数一起预估，避免后期返工。

3.2 分片过多

每个分片都是一个 Lucene 索引，消耗文件句柄、内存与 CPU，即使空闲也有集群元数据开销。分片过多会导致查询合并变慢、重启恢复拖长、主节点压力增大。经验法则：单个分片建议 20--50GB；单节点每 GB 堆内存对应非冻结分片不超过 20 个。

|----------------------------------------------------------------|
| # 查看分片分布与状态 |
| GET /_cat/shards?v |
| # 已建大索引分片过多时的补救：重建 |
| POST /_reindex |
| {"source": {"index": "log_old"}, "dest": {"index": "log_new"}} |

3.3 分片过少

数据量远超单分片 50GB 却只建少量分片，单个分片过大导致均衡、恢复与合并困难。合理做法是按时序索引（如按天/周）搭配适度分片，配合滚动索引（ILM）管理。

四、写入与集群水位陷阱

4.1 磁盘水位触发只读块

节点磁盘达到 flood-stage 水位（默认 95%）时，索引会进入 read-only-allow-delete 块，写入被拒、Kibana 等系统索引受影响。解法是清理或扩盘、调整水位阈值，并配合索引生命周期及时归档冷数据。

4.2 大 bulk 与线程池拒绝

单次 bulk 过大或写入过快会打满 write 线程池，出现 429 rejected（_cat/thread_pool/write 可见 rejected 增长）。应控制 bulk 批次大小、降低刷新频率（index.refresh_interval）或调大 index buffer，而不是盲目加压。

4.3 集群健康停留在 yellow

副本分片未分配（如节点不足或磁盘不足）时集群为 yellow，数据无冗余、节点宕机即丢数据。用 _cluster/allocation/explain 定位未分配原因并补齐节点/副本。

五、查询陷阱

5.1 深分页 from + size

from 很大时，ES 仍需在分片内排序后取整段窗口，from 越大开销越大、内存风险越高。正确做法是用 search_after 做游标翻页，避免跳页式深分页。

5.2 通配符与大范围查询

前缀/通配符（a*）会扫描大量词项；terms 一次塞入过万值或命中全量文档的大范围过滤，都会显著拖慢查询。应约束查询宽度、配合过滤器缓存。

5.3 用 Profile API 定位慢查询

|-----------------------------------|
| GET /article/_search |
| {"query": {...}, "profile": true} |
| # 返回每个子查询与分片耗时，定位热点子句 |

结合 _cat/thread_pool/search 与慢查询日志（index.search.slowlog），能快速定位是查询写法还是分片分布导致的慢。

六、内存与运维陷阱

6.1 堆内存超过节点一半

堆内存不建议超过物理内存一半且不超过约 30GB（指针压缩失效）。堆过大挤压文件缓存与操作系统内存，反而触发频繁 GC。合理做法是控制堆、把内存留给 Lucene 页缓存。

6.2 无认证暴露公网

ES 默认绑定本地回环；若对外开放且未启用安全认证，任何人都能删改数据，是常见入侵入口。生产必须开启 xpack 安全或置于可信内网，并用防火墙收紧 9200/9300。

|---------------|------------|----------------|
| 问题 | 危害 | 规避 |
| 映射爆炸 | 变慢、内存飙升 | 收敛动态映射 / 限字段 |
| 主分片不可改 | 容量规划返工 | 前瞻分片 + reindex |
| 分片过多 | 查询慢、恢复慢 | 单分片 20-50GB |
| 磁盘水位只读 | 写入被拒 | 清理扩盘 + ILM |
| 深分页 from+size | 内存风险 | 用 search_after |
| 无认证暴露公网 | 被入侵、删数据 | xpack 安全 + 防火墙 |

七、本篇小结

避坑的本质是让检索链路「稳定可控」：映射阶段收敛动态字段、显式定义类型，避免映射爆炸；分片阶段前瞻规划 20--50GB 单分片并配合 ILM；写入与水位阶段控制 bulk、监控磁盘阈值；查询阶段用 search_after 替代深分页、用 Profile 定位热点。映射、分片、写入、查询与安全协同治理，ES 才能在亿级数据下稳定可控。

下一篇进入调优实战，聚焦写入优化、查询调优与监控体系。