清理一个或多个索引的缓存，释放内存资源。
API #
POST /_cache/clear
POST /{index}/_cache/clear
API 的作用 #
该 API 用于清理索引的缓存，可以释放内存资源。支持清理以下类型的缓存：
| 缓存类型 | 描述 |
|---|---|
| query cache | 查询缓存，存储查询执行的中间结果 |
| field data cache | 字段数据缓存，存储聚合和排序时的字段数据 |
| request cache | 请求缓存，存储最近请求的响应 |
| fields | 特定字段的字段数据缓存 |
使用场景 #
- 释放内存压力
- 清除过时的缓存数据
- 测试查询性能（无缓存）
- 节点维护前清理资源
注意：清除缓存是资源密集型操作，建议在低峰期执行。
API 的参数 #
路由参数 #
| 参数 | 类型 | 是否必填 | 描述 |
|---|---|---|---|
{index} | 字符串 | 否 | 要清理缓存的索引名称。支持：单个索引、逗号分隔的多个索引、通配符表达式、_all（所有索引） |
Query String 参数 #
缓存类型参数 #
| 参数 | 类型 | 是否必填 | 默认值 | 描述 |
|---|---|---|---|---|
query | 布尔值 | 否 | false | 是否清理查询缓存 |
fielddata | 布尔值 | 否 | false | 是否清理字段数据缓存 |
request | 布尔值 | 否 | false | 是否清理请求缓存 |
fields | 列表 | 否 | 无 | 当 fielddata=true 时，指定要清理的字段列表（逗号分隔） |
索引选项参数 #
| 参数 | 类型 | 是否必填 | 默认值 | 描述 |
|---|---|---|---|---|
ignore_unavailable | 布尔值 | 否 | false | 当指定索引不可用时是否忽略（缺失或关闭） |
allow_no_indices | 布尔值 | 否 | false | 当通配符没有匹配到索引时是否忽略 |
expand_wildcards | 枚举值 | 否 | open | 通配符展开选项。可选值：open、closed、hidden、none、all |
示例 #
清理所有索引的所有缓存 #
POST /_cache/clear
响应示例：
{
"_shards": {
"total": 10,
"successful": 10,
"failed": 0
}
}
清理所有缓存类型 #
POST /_cache/clear?query=true&fielddata=true&request=true
清理特定索引的缓存 #
POST /my_index/_cache/clear
清理多个索引的缓存 #
POST /index1,index2/_cache/clear
只清理查询缓存 #
POST /my_index/_cache/clear?query=true
只清理字段数据缓存 #
POST /my_index/_cache/clear?fielddata=true
只清理特定字段的字段数据 #
POST /my_index/_cache/clear?fielddata=true&fields=field1,field2
清理请求缓存 #
POST /my_index/_cache/clear?request=true
使用通配符清理缓存 #
POST /logs-*/_cache/clear?query=true
只清理打开的索引（默认） #
POST /*/_cache/clear?expand_wildcards=open
清理所有索引（包括关闭的） #
POST /*/_cache/clear?expand_wildcards=all
响应字段说明 #
| 字段 | 类型 | 描述 |
|---|---|---|
_shards.total | 整数 | 总分片数 |
_shards.successful | 整数 | 成功的分片数 |
_shards.failed | 整数 | 失败的分片数 |
缓存类型详解 #
Query Cache（查询缓存） #
- 作用：缓存查询结果，提高重复查询性能
- 清理时机：索引更新后可能需要清理
- 内存占用：中等
Field Data Cache（字段数据缓存） #
- 作用：缓存字段数据用于聚合和排序
- 清理时机：字段数据量大时可以释放内存
- 内存占用：通常最大
- 注意：清理后聚合和排序性能会下降
Request Cache（请求缓存） #
- 作用：缓存完整的搜索请求响应
- 清理时机：数据更新后需要清理
- 内存占用：较小
使用场景 #
场景 1：释放内存压力 #
当节点内存使用率高时：
# 清理所有索引的缓存
POST /_cache/clear?query=true&fielddata=true&request=true
场景 2：测试查询性能 #
测试无缓存情况下的查询性能：
# 清理查询缓存
POST /my_index/_cache/clear?query=true
# 执行测试查询
GET /my_index/_search
{ ... }
场景 3：索引更新后 #
大量数据更新后清理缓存：
# 数据更新完成
POST /my_index/_bulk
{ ... }
# 清理缓存以确保查询使用新数据
POST /my_index/_cache/clear
场景 4：清理特定字段 #
只清理占用内存大的字段：
POST /my_index/_cache/clear?fielddata=true&fields=large_field1,large_field2
性能考虑 #
清理缓存的影响 #
| 方面 | 影响 |
|---|---|
| 内存释放 | 立即释放内存 |
| 查询性能 | 短期内下降，需要重新构建缓存 |
| 聚合性能 | 字段数据缓存清理后显著下降 |
| 资源消耗 | 清理过程本身消耗 CPU 和 I/O |
最佳实践 #
- 低峰期执行：在业务低峰期执行，避免影响正常服务
- 选择性清理：只清理需要清理的缓存类型
- 特定索引：优先清理占用内存大的索引
- 监控内存：清理后监控内存使用情况
- 避免频繁清理：频繁清理会降低整体性能
注意事项 #
- 性能下降：清理后查询和聚合性能会暂时下降
- 缓存重建：缓存需要在使用时重新构建
- 全局影响：清理会影响使用该索引的所有查询
- Field Data 警告：字段数据缓存通常占用内存最大，清理后重建时间最长
- 谨慎使用通配符：使用通配符清理大量索引时要注意性能影响
缓存相关设置 #
可以通过索引设置调整缓存大小：
{
"index.queries.cache.size": "10%",
"index.fielddata.cache.size": "40%",
"indices.requests.cache.size": "5%"
}
