#日志索引与查询优化

日志系统的查询性能直接决定了故障排查的效率。当一次故障发生时，运维人员需要在秒级时间内完成「海量日志的定位和过滤」，这要求底层存储和查询引擎都经过精心优化。索引设计是性能的基础，分片策略是扩展性的保障，查询优化是用户体验的核心。

日志索引与普通数据库索引有本质区别：日志查询通常是范围扫描 + 关键词过滤（「过去 1 小时包含 ERROR 的日志」），而不是点查询；日志数据量大但查询量相对小，不需要像 OLTP 数据库那样优化高并发点查询。

#索引设计原则

对于 Elasticsearch 存储的日志，索引设计的核心原则是平衡索引粒度和查询效率。过粗的索引粒度（如按月）会导致单索引过大，查询和删除效率低下；过细的索引粒度（如按分钟）会产生大量小索引，增加协调节点开销。

推荐的时间分片策略是：按天创建索引，单个索引控制在 50GB 以内。如果单日日志量超过 50GB，按小时分片；如果单日日志量只有几 MB，可以按周分片。副本数量根据可用性要求配置：生产环境至少 1 副本，允许少量数据丢失的场景可以 0 副本。

#映射优化

Elasticsearch 的动态映射会在首次写入时自动推断字段类型，但这可能导致性能问题。对于日志数据，建议显式定义映射，关闭不需要的字段索引。

{
  "mappings": {
    "properties": {
      "timestamp": { "type": "date" },
      "level": { "type": "keyword" },
      "service": { "type": "keyword" },
      "message": { "type": "text", "index": false }
    }
  }
}

关键优化点：timestamp 使用 date 类型便于时间范围查询；level、service 等分类字段使用 keyword 类型（不支持全文检索但查询高效）；message 使用 text 类型但设置 index: false 如果不需要内容搜索（可以节省 30-50% 存储空间）。

#查询优化技巧

查询优化的第一步是尽量缩小范围。在 Kibana Discover 中，先选择时间范围和过滤器（如 level:ERROR），再进行全文搜索。Elasticsearch 的倒排索引在范围过滤后数据量已经大大减少，全文搜索的代价也相应降低。

避免查询 match 所有字段（*_all 或 multi_match without fields）。当需要跨多个字段搜索时，明确指定字段列表，因为默认的 _all 字段会包含所有文本内容，增加查询开销。

使用 filter 而非 query 进行精确匹配。filter 不计算相关性得分，Elasticsearch 可以缓存 filter 结果，性能更高。