把日志当数据库查：OBSERVE SQL 检索从入门到调优

为什么要在日志上跑 SQL

关键词检索是“找”——找到包含某个关键词的日志。但排查和运营真正要回答的问题，大多不是“有没有”，而是“有多少、怎么分布、什么趋势”：今天 5xx 错误占比多少？哪个接口的 P99 延迟最高？昨天凌晨流量为什么掉了一半？这些问题没有单条日志能回答，答案藏在几百上千万条日志的聚合结果里。手工导出再用脚本统计，既慢又容易拖垮存储；在检索框里手写 SQL，一条语句就能同时拿到明细和统计。

OBSERVE 在采集侧把日志里的公共字段（时间戳、级别、服务名、trace_id、HTTP 状态码、耗时、来源 IP）解析成结构化字段，检索框支持标准 SQL 子集，可以直接在日志数据上做过滤、分组、聚合和排序。

基础语法：一条语句同时拿明细和统计

语法沿用标准 SQL，最常用的是 SELECT、WHERE、GROUP BY、ORDER BY、LIMIT，时间范围由页面右上角的选择器控制，也可显式指定。先看三个最常用的例子：

-- 按服务统计近 1 小时错误数，倒序取前 10
SELECT service, count(*) AS err_count
FROM log
WHERE level = 'ERROR'
GROUP BY service
ORDER BY err_count DESC
LIMIT 10;

-- 各 HTTP 状态码占比（百分比）
SELECT status, count(*) * 100.0 / sum(count(*)) OVER () AS pct
FROM log
WHERE status >= 400
GROUP BY status;

-- 找出 P99 延迟最高的 5 个接口
SELECT api, approx_percentile(duration_ms, 0.99) AS p99
FROM log
WHERE duration_ms IS NOT NULL
GROUP BY api
ORDER BY p99 DESC
LIMIT 5;

聚合函数除 count、sum、avg、min、max 外，还提供 approx_percentile、approx_distinct 等近似函数，面向大基数场景，误差可控、速度提升一个量级。

常用查询模板（可直接复制）

慢接口定位：按接口维度统计平均与 P99 耗时，快速锁定拖后腿的服务。错误率突增：按分钟统计错误数，配合时序图观察拐点出现的时间，再结合发布记录定位变更。用户维度分析：按来源 IP 或用户 ID 分组，判断是个别用户异常还是全局故障。关联查询：带 trace_id 的日志按 trace_id 聚合，还原一次请求的完整调用链。

这些模板的共同思路是“先聚合、再明细”：先用聚合结果缩小范围，再带着条件（某个接口、某个时间段）去查明细日志，避免全表扫描。

性能与最佳实践

SQL 检索虽灵活，写不好也会慢。几条实践建议：第一，优先用字段过滤而不是全文模糊匹配，status >= 400 比 message LIKE '%error%' 快得多，结构化字段走索引。第二，时间范围尽量收窄，聚合类查询的时间跨度决定扫描量。第三，聚合查询记得加 LIMIT，避免一次返回几十万行。第四，跨天、跨全量的大聚合走预聚合指标，不要每次现算。第五，善用采样：排查占比、趋势类问题时，10% 采样往往足够看清结论，速度却能快十倍。

把日志从“可搜”变成“可算”，是日志平台对排查效率最大的提升。下一篇我们会讲如何把这些聚合查询固化成告警。