_count 做什么
_count 只返回匹配条件的文档数量，不返回 hits、也不做聚合，因此比 search 轻量得多。它最常用在批量操作之前核对影响范围，比如执行 delete_by_query 或 reindex 之前先确认这次到底会动到多少文档。
基本信息
| 接口 | GET /<index>/_count 或 POST，请求体只放 query |
|---|---|
| 返回内容 | count 字段与 _shards 信息 |
| 不支持的参数 | from、size 与聚合都不适用，它只回答数量 |
| 简写形式 | GET /logs/_count?q=status:error 直接用查询串 |
| 权限要求 | 索引读权限即可 |
典型使用场景
- 批量删除或批量更新前核对影响范围
- 数据质量巡检：统计缺字段、异常状态的文档数量
- 写入校验：确认导入后文档数是否符合预期
- 对比不同时间点的数量变化，判断数据增长趋势
- 调试查询条件：先看命中数，再决定要不要返回正文
常用写法
常用写法
# 统计满足条件的文档数
GET /my-index/_count
{ "query": { "term": { "status": "open" } } }
# 用查询串语法快速统计
GET /logs/_count?q=status:error
# 批量删除前核对影响范围
GET /logs-2024/_count
{ "query": { "range": { "@timestamp": { "lt": "now-90d" } } } }
# 不带条件即统计整个索引的文档数
GET /my-index/_count返回字段读法
| 字段 | 含义 | 注意 |
|---|---|---|
| count | 匹配到的文档总数 | 随刷新节奏变化，写入高峰两次结果可能不同 |
| _shards.total | 参与查询的分片数 | 与索引分片数一致说明查询正常 |
| _shards.successful | 成功返回的分片数 | 小于 total 说明存在不可用分片 |
| _shards.failed | 失败分片数 | 非 0 时结果可能不完整 |
_count 的数字来自各分片的统计，非常轻量，但会随刷新节奏变化：写入高峰期短时间内两次调用可能得到不同结果，把它当成强一致快照会误判。
执行 delete_by_query、update_by_query 或 reindex 之前先用 _count 核对数量，是最省事的防误操作习惯；数量与预期差一个量级时，多半是查询条件写错了。
无条件统计超大索引的文档数仍要访问所有分片，高频调用会持续消耗资源；监控采集要控制频率，别把核对手段变成新的压力来源。