Elasticsearch：delete_by_query使用方法
首先，在大数据量下，不推荐使用delete_by_query的方案进行数据删除，这种方式会给es集群的cpu、内存、io带来巨大的压力，集群有down机的风险。
1、delete_by_query是什么？
_delete_by_query 是一个用于根据查询条件批量删除文档的 API，它会对每个与查询条件匹配的文档执行删除操作，在执行删除操作的过程中，如果文档发生变更，这时就会出现版本冲突，删除操作就会停止，我们可以通过conflicts参数来控制版本冲突时是否停止。
_delete_by_query执行的是逻辑删除，它只是标记这个文档为已删除状态，并不会立即释放磁盘空间。而是在后续的段合并（segment merge）操作中，才会将这些已删除的文档从磁盘上清除。
2、_delete_by_query使用方法
基本语法：
POST //_delete_by_query
{
"query": {
// 查询条件，与 Search API 的语法相同
"match": {
"field": "value"
}
}
} index：要删除文档的索引名称，可以是单个索引，也可以是多个索引（用逗号分隔），还可以使用通配符。
-
删除es中start_time大于1732982373655的所有文档：
POST /new_tag_202411_new/_delete_by_query
{
"query": {
"bool": {
"filter": [
{
"range": {
"start_time": {
"gte": 1732982373655
}
}
}
]
}
}
}-
删除多个索引中的文档
POST /new_tag_202411_new,twitter/_delete_by_query
{
"query": {
"bool": {
"filter": [
{
"range": {
"start_time": {
"gte": 1732982373655
}
}
}
]
}
}
}-
请求参数说明：
query
必填参数，用于定义删除文档的查询条件，语法与 Search API 相同。
conflicts
可选参数，默认为 abort（中止），当设置为 proceed 时，即使遇到版本冲突也会继续执行删除操作，并统计冲突数量。
refresh
可选参数，默认为 false。设置为 true 时，在请求完成后刷新涉及的所有分片，该变更对搜索立即可见。
wait_for_completion
可选参数，默认为 true。设置为 false 时，Elasticsearch 将异步执行删除操作，并返回一个任务 ID，可通过任务 API 获取任务状态或取消任务。
wait_for_active_shards
可选参数，控制在继续执行请求之前必须激活多少个分片副本。
timeout
可选参数，控制每个写请求等待不可用分片变为可用的时间。
requests_per_second
可选参数，用于限制每秒发出的删除请求数量，设置为 -1 可禁用限流。
scroll_size
可选参数，用于设置滚动查询的批次大小，默认为 1000。
routing
可选参数，将路由值复制到滚动查询中，将删除操作限制在与该路由值匹配的分片上。-
api返回：
{
"took": 29,
"timed_out": false,
"total": 1,
"deleted": 1,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1,
"throttled_until_millis": 0,
"failures": []
}执行 _delete_by_query 操作后，Elasticsearch 会返回一个 JSON 格式的响应，各字段含义如下：
took
整个操作从开始到结束所花费的时间（毫秒）。
timed_out
是否超时。
total
成功处理的文档数。
deleted
成功删除的文档数。
batches
分批处理的批次数量。
version_conflicts
版本冲突的文档数。
retries
操作尝试的重试次数，包括批量操作和搜索操作的重试次数。
throttled_millis
请求休眠以符合 requests_per_second 参数设置的毫秒数。
failures
如果请求处理中有任何不可恢复的错误，会记录到这个失败数组中。3、_forcemerge合并段+物理删除文档
forcemerge 是 Elasticsearch 中用于优化索引存储和查询性能的操作，通过合并段（segments）来减少文件数量，从而提升查询效率+释放被删除文档占用的磁盘空间。
_delete_by_query只是标记删除，并没有真正的执行删除操作，只有运行_forcemerge后，才会释放占用的磁盘空间。
_forcemerge的核心作用：
- 减少段数量
-
Elasticsearch 索引由多个段（segments）组成，每个段是一个独立的倒排索引。
随着文档的增删改查，段数量会不断增加，导致查询时需要扫描更多文件，降低性能。
-
forcemerge将多个段合并为一个或者少量段，减少文件数量，提升查询效率。
-
- 释放被删除文档占用的空间
-
删除文档时，Elasticsearch 不会立即删除物理文件，而是标记为删除。
-
合并段时，这些被标记为删除的文档会被真正移除，释放存储空间。
-
_forcemerge的基本用法：
合并所有段位为1段：
POST /my_index/_forcemerge?max_num_segments=1仅合并有删除文档的段：
POST /my_index/_forcemerge?only_expunge_deletes=true_forcemerge参数详解：
| 参数名 |
类型 |
默认值 |
说明 |
|---|---|---|---|
max_num_segments |
int |
1 |
合并后的段数量。设为1时合并为一个段，设为N时合并为最多N个段。 |
only_expunge_deletes |
bool |
false |
是否仅合并包含被删除文档的段。设为true时，仅释放空间，不减少段数量。 |
flush |
bool |
true |
是否在合并后刷新索引。设为false时，合并后不立即刷新，可能提升性能。 |
4、注意事项
【资源消耗大】forcemerge过程非常消耗cpu、磁盘io，一定要在低负载期间运行。
【不可逆】合并后的段不能再【拆分】。
segment merge完全完成后，才会真正释放存储空间。
总的来说，文档删除在es中不推荐，forcemerge的风险很高，在实际工作中千万要谨慎，因为我们在执行这个操作时，es被打满服务直接跪了，所以务必小心，清理es，推荐的方式是索引删除，索引删除直接就是物理删除，不涉及段合并，安全且高效率，后面介绍一下es的【ilm】机制，实现索引的自动删除，非常之方便。
欢迎各位热爱技术的小伙伴们点个关注，聊聊跑步、聊聊技术~~~。
往期推荐
我在百度的这10年~~
大同华严寺：受人民爱戴的耿市长还会回来吗？薄伽教藏的合掌漏齿菩萨你知道是谁吗？
云冈石窟：翻开这本距今1565年、与天地同久长的石头史书，感受北魏王朝雕刻艺术的巅峰之作。
历经沧桑的应县木塔，在风雨中已等你969年。
从北京到大同，走过600里，跨越1000年。
RabbitMq：消费侧未限流导致的rabbitmq报错异常，消息不能正常消费。
一个异步架构设计：批量消费RabbitMQ，批量写入Elasticsearch(golang实现)
一个读写excel的简单程序(golang)
Python Tortoise ORM库的基础操作介绍
不告诉你Sanic Blueprints、Middleware是如此的优雅。
Python web框架sanic+tortoise服务框架搭建(MVP版本)
一个优秀的rabbitmq消费者(consumer)设计，可直接上线使用。
supervisor，你理应知道。
命令行参数的艺术：Python、Golang、C++技术实现
借助tritonserver完成gpt2模型的本地私有化部署
一文揭秘：Golang+Elasticsearch轻松搭建AI时代的图片搜索服务
吭哧一天才搞定：elasticsearch向量检索需要的数据集以及768维向量生成
Elasticsearch滚动查询官方推荐方案：search_after检索实现（golang）
protobuf c++开发快速上手指南
ElasticSearch向量检索技术方案实现
2025年，我要做个自我介绍