Refresh 与近实时是什么
Elasticsearch 的索引是近实时（near real-time）的：文档写入后先进内存缓冲区，默认每秒 refresh 一次生成新的可搜索段，之后才能被检索到，因此「写完立刻查」通常查不到。需要即时可见时可以显式指定 refresh=wait_for 或 true，代价是更频繁的段生成与合并压力。日志场景一般接受秒级延迟，只有写入后立刻要读的流程才需要干预。
基本信息
| 默认行为 | 每秒 refresh 一次 |
|---|---|
| 可见性控制 | 写入时加 refresh=wait_for 或 refresh=true |
| 索引级设置 | index.refresh_interval |
| 适用版本 | Elasticsearch 7.x / 8.x |
| 性能代价 | 刷新越频繁，批量写入吞吐越低 |
典型使用场景
- 写入后立即查：数据同步任务写完马上要读，用 wait_for 保证可见
- 测试验证：功能测试里需要立即断言文档已经可检索
- 批量导入：导入期间临时调大刷新间隔提升吞吐，结束再调回
- 延迟排障：Kibana 里看不到刚写入的日志时，先确认是不是刷新的正常延迟
- 性能调优：写入密集的日志索引放宽刷新间隔，降低段合并压力
使用要点
- wait_for 只等待下一次刷新，并非立刻生效，语义上比 true 温和
- 生产环境慎用 true，每个请求都触发刷新会显著削弱吞吐
- 调整刷新间隔要结合查询侧对可见延迟的预期一起定
- 批量导入结束后记得把刷新间隔调回，避免长期处于低可见性
- 排查「数据没进去」之前，先确认是否是刷新延迟造成的
可见性控制
可见性控制
# 写入后立即可见（小批量或测试用，生产慎用 true）
PUT /logs-app/_doc/1?refresh=wait_for
{ "@timestamp": "2026-10-12T10:00:00Z", "msg": "test" }
# 调整刷新间隔（写入密集场景可放宽）
PUT /logs-app/_settings
{ "index.refresh_interval": "30s" }
GET /logs-app/_settings?include_defaults=true # 查看当前设置取值对照
| 取值 | 语义 | 适用 |
|---|---|---|
| 不指定 | 按刷新间隔自然可见 | 绝大多数场景 |
| wait_for | 等待下一次刷新后返回 | 写入后要立刻查 |
| true | 立即刷新 | 测试或极小批量写入 |
| refresh_interval | 索引级刷新周期 | 写入密集时放宽 |
| 默认 1 秒 | 近实时的来源 | 延迟排查的基准 |
秒级延迟通常完全可以接受，只有写入后必须马上读到的流程才值得为它付出额外的刷新成本。