搜索系列 · 第 07 篇——调优实战：写入、查询与监控

把 Elasticsearch 的性能与稳定性调到最佳

一、导读

前几讲解决了「能跑、能高可用、能避坑」，本讲聚焦「跑得快、看得清、扛得住」：从写入调优、索引生命周期、查询优化到监控体系，把调优方法论落到可执行的配置与命令上。

二、写入调优

2.1 用 bulk 批量写入

逐文档写入吞吐远低于批量写入。应用 bulk 接口一次提交多文档，可大幅减少网络往返与线程池压力；bulk 大小需实测，通常数 MB 到数十 MB 一档：

|----------------------------------------------|
| curl -s -XPOST http://es01:9200/_bulk |
| {"index":{"_index":"article"}} |
| {"title":"NoSQL 实战","content":"..."} |
| {"index":{"_index":"article"}} |
| {"title":"Elasticsearch 调优","content":"..."} |

2.2 刷新与缓冲调优

高频写入场景，默认每约 1 秒 refresh 会产生大量小段。日志等可容忍延迟的场景可调大 index.refresh_interval 并适当提升 index buffer，换取更高写入吞吐：

|-------------------------------------------------------------|
| PUT /article/_settings |
| {"index": { |
| "refresh_interval": "30s", |
| "number_of_replicas": 0 |
| }} |
| # 集群级 index buffer（默认 10%） |
| PUT _cluster/settings |
| {"persistent": {"indices.memory.index_buffer_size": "20%"}} |

批量导入时暂关副本、调大 refresh 间隔，导入完成后再恢复，可显著提速；注意恢复副本后等待其分配完成。

2.3 线程池与 backoff

写入打满 write 线程池会出现 429 rejected。合理压测 bulk 大小、控制并发，必要时提升节点或分片均衡，而不是无限加大批量。

三、索引生命周期与分片策略

3.1 ILM 冷热数据分离

时序数据（日志、监控）随时间为准点写入，用索引生命周期管理（ILM）把索引按 hot → warm → cold → delete 四阶段自动流转，配合冷热节点实现存储成本优化：

|------------|------------------|------------|
| 阶段 | 行为 | 用途 |
| hot | 实时写入，rollover 滚动 | 处理高频写入 |
| warm | 不再写入，提供查询 | 历史查询 |
| cold | 低频率查询，迁移冷节点 | 归档冷数据 |
| delete | 到期删除 | 控制存储成本 |

结合索引模板 + 别名 + rollover，新数据自动滚动到新索引，旧索引按策略自动流转，避免单索引无限膨胀。

3.2 分片规划

单分片建议 20--50GB；时序索引按天/周创建、每索引分片适中（1--3 个），总量估算用「总数据量 / 30GB」。主分片创建后不可改，务必前瞻规划。

四、查询调优

4.1 用过滤器缓存与精确字段

把命中范围大、不变或低频变化的过滤条件（如状态、类型）放进 filter 上下文，可命中查询过滤器缓存；高频精确过滤字段用 keyword 而非 text，避免无谓分词。

4.2 避免深分页与大 from

深分页 from+size 开销随 from 增大而增长，应改用 search_after 游标翻页；需要大量数据的导出可用 scroll 或 PIT（point-in-time）快照。

4.3 用 Profile API 定位慢查询

|----------------------------------------------------------------------------|
| GET /article/_search |
| {"query": {...}, "profile": true} |
| # 返回子查询与分片耗时分布 |
| GET /_cat/thread_pool/search?v&h=node_name,name,active,rejected,completed |

排查路径：先看 _cat/shards 分片状态与分布，再看线程池 rejected 与队列，最后用 Profile 定位热点子句；配合慢查询日志（index.search.slowlog）沉淀规律。

五、监控体系

5.1 内置命令巡检

|-----------------------------------------------------------------------------------------------|
| curl -s http://es01:9200/_cat/health?v # 集群健康 |
| curl -s http://es01:9200/_cat/nodes?v # 节点状态 |
| curl -s http://es01:9200/_cat/shards?v # 分片分布 |
| curl -s http://es01:9200/_cat/thread_pool/write?v\&h=node_name,name,active,rejected,completed |

5.2 关键指标

|--------------|---------------------|
| 指标 | 关注点 |
| 集群健康 | green/yellow/red 三色 |
| 线程池 rejected | 写入/查询是否打满 |
| 堆内存使用 | 是否持续高位、频繁 GC |
| 磁盘水位 | 是否触发只读块 |
| 查询延迟 / 吞吐 | 定位慢查询与瓶颈 |

5.3 全链路监控

生产推荐 Prometheus + Grafana：通过 Elasticsearch Exporter 暴露节点指标，Grafana 绘制大盘并告警，配合 _cat 命令、慢查询日志与 JMX（JVM GC/堆）做完整排障，实现可观测闭环。

六、本篇小结

调优是一套「先量化 → 再优化 → 后验证」的方法论：写入用 bulk 批量、调 refresh 与 index buffer；时序数据用 ILM 冷热分离与合理分片；查询用过滤器缓存、search_after 与 Profile 定位；监控用 _cat 命令与 Prometheus 组合。调优目标是让 ES 稳定、可控、可观测。

下一篇进入面试收官，汇总高频面试题与全景总结，为系列收尾。