云联信息：日志检索慢，多半是索引没配好

2026-11-05 1次浏览

日志服务上线之后，查一次报错要等半分钟，越用越不想用。原因通常不是数据量大，而是索引配置不合理：该建索引的字段没建，不该建的建了，查询时全表扫描。

先明确要查什么

排查问题通常按时间、服务名、错误码、请求ID 查。这四类字段建索引，其余字段按需开启，索引量能降一半以上，查询速度明显提升。

全文索引方便，但占用空间大、写入慢。日志量大时，建议只对关键内容开全文索引，其余用字段精确匹配，成本差别很大。

查询时不带时间范围，等于扫描全部数据。默认带上最近一小时，需要时再放宽，这是最简单的提速手段。

不同服务写不同日志库，或者用字段区分。混在一个库里，查询时噪音多，定位效率低。

高并发服务的访问日志，全量写入成本很高。按比例采样，排查问题足够用，成本能降一个量级。

访问日志保留七天、错误日志保留三十天、审计日志保留一百八十天。统一保留一年，费用会高得离谱。

把常见错误的查询保存下来，配置成告警规则。日志不只是事后查，还能变成主动发现问题的工具。

写入慢是采集端的问题，查询慢是索引的问题，两者排查方向完全不同。先确认是哪一头慢，再动手优化。

字段索引建好之后，查询写法也很关键。前缀通配符、正则、大范围时间扫描，都会让索引失效。把常用查询固化下来，写好就用，避免临时手写出问题。

请求ID 贯穿前后端日志，排查时按 ID 一查就能串起整条链路。没有这个关联字段，只能靠时间戳猜，效率差很多。

日志不是越多越好。把高价值的错误日志、审计日志留久一点，访问日志短一点。策略清楚之后，既省钱又不影响排查。

索引越多写入越慢，存储也越贵。建索引前先想清楚要查什么，比建完再删省事。

常用查询存成模板，字段、时间范围、过滤条件都固定。临时手写容易漏条件，扫全量数据还慢。

日志系统的价值在于能用，而不是存得多。云联信息【资深云服务专家微信：cloud7591】的建议是先按排查习惯梳理四五个关键字段，索引只建这些，其余按需开启，速度和成本都能接受。

最后提醒一句：索引调整之后观察一周再定稿，报错的查询和新出现的慢查询都要看一遍，改动总会带来新的影响。