结论先行：日志平台上线之后，最常听到的抱怨不是「日志存不下」，而是「查得太慢」。同一段时间范围、同一批数据，有人十秒出结果，有人十分钟还在转。差别多数不在平台，在查询被写成了什么样：时间范围从多宽开始、条件里有没有用上已经提取的字段、关联两张表之前有没有先缩小范围、结果要不要全量排序。把这四件事定成写法约定，比给平台加机器更省。本文只谈查询本身怎么写才快、慢在哪一层怎么判断，不谈平台底座选自研引擎还是开源引擎，也不谈日志该留多久、存在哪一层介质上。
先分清慢在哪一层
一次查询的耗时由三段构成，三段的对策完全不同，混着谈就会得出「加机器」这种不解决问题的结论。
- 数据层：这段时间要扫的日志有多少条。范围定得越宽，这一段越贵。它跟写法的关系最大，因为范围是你自己给的。
- 计算层：条件能不能落到已经建好的字段上。用字段做等值匹配，和用一段文本去全文撞，代价差一到两个数量级。
- 结果层：要不要把命中的全部记录排完序再取前几条，要不要在这上面再叠聚合。结果层的开销常常被忽略，因为它发生在「已经查到了」之后。
做法很简单：拿一条你觉得慢的查询，把时间范围先缩到一小时，看耗时；再把条件一条一条加上去，每加一条记一次耗时。哪一步耗时跳变，问题就在那一层。这个动作五分钟能做完，比凭感觉猜准得多。
四个最常见的写法问题
在多数企业的日志平台上，慢查询的成因高度集中，来来回回是这四类。
| 写法 | 为什么慢 | 改法 |
|---|---|---|
| 时间范围先拉到一个月，再用条件筛 | 先按范围把数据全取出来，再逐条过滤，绝大多数记录白扫一遍 | 先定最小可信范围，从一两小时起，确认真没有结果再往外扩 |
| 放着已提取的字段不用，改成一段文本去撞 | 字段匹配走索引，文本匹配要逐条比对内容，代价差一到两个数量级 | 接入时已经把源地址、账号、操作时间、操作行为提取成字段，查询就直接用字段 |
| 两张表先关联再过滤 | 关联是乘法，两侧没缩小就先关联，中间结果会大到没边 | 两侧各自先筛到几百条，再关联 |
| 排序与聚合不设边界 | 对全部命中记录排序，取前十条也要先把百万条排完 | 先给条数上限，聚合前先缩小范围 |
四类里，第二类最容易被误判成平台性能问题。用户的直觉是「我输了关键词，它就该很快搜到」，但如果这句话在平台眼里是全文匹配，快不起来是必然的。
字段决定了查询能跑到多快
查询速度的上限，其实在接入那天就定了大半。日志进来时如果只当作文本存着，后面无论怎么优化查询写法，能提升的空间都有限；反过来，接入时用解析规则把常见格式拆成结构化字段，后面的查询才有可用的抓手。
成熟平台的做法是内置一批通用解析规则，覆盖常见格式与协议，自动提取源地址、账号、操作时间、操作行为、目标资产这几类关键字段，再把时间戳统一、敏感信息脱敏。这一步做完，一条「谁在什么时间从哪台机器登上了哪台服务器」的查询，就从「全文撞三个词」变成了「三个字段各等值匹配」，耗时不在一个量级。
所以判断「该不该给平台加机器」之前，先问一句：这条查询里，有几个条件是真的落在字段上的。如果一个都没有，加机器只会让白扫得快一点。
把高频查询存下来，别让每个人重写
同一批人会反复问同一类问题：昨天谁改了配置、某个账号最近从哪登录、某个错误码集中在哪几台机器。这些查询写对一次之后就该固化，做成模板、仪表盘或定时任务，而不是每次重新拼。
模板化的好处有三层。其一，写法是验证过的那一版，不会因为某个人换了写法又变慢；其二，口径统一，两个人问同一件事得到同一个数；其三，新人不用从零学查询语言，选模板、改参数就能用。多数平台都支持把页面写的查询语句直接存成模板，不需要开发介入。
反过来，如果平台上线一年了，还只有两个人会写查询，其余人靠找这两个人帮忙，那这个平台实际上只发挥了一部分作用，问题不在工具。
什么时候确实是平台该扩容了
不是所有慢都怪写法。有三种情况属于平台侧的真实信号，需要单独判断。
- 同一条查询、同一段时间范围，耗时随总量增长而变长：写法没变，数据在涨，这是容量问题。
- 写入侧出现延迟：日志进来的时间与事件发生的时间差在拉大，说明入库排队，跟查询无关。
- 并发一高就慢：单个人跑得快，十个人同时跑就排队，这是资源争抢。
判断方法也简单：把同一条查询在月初和月末各跑一次，比较耗时。数字稳定说明写法是主要变量；数字在涨，才轮到容量。
一个反例：加了两台机器，查询没变快
某个项目反馈「日志平台越用越慢」，当时的反应是容量不够，于是加了两台节点。加完之后慢查询的耗时基本没动，写入侧倒是顺了一些。复盘时抽了十条被投诉的查询逐条看，八条是全文匹配，两条把时间范围拉到三十天再筛。改写之后，同样十条查询里七条落到十秒以内，另外三条再配上范围习惯，也回到了可接受的水平。
这个反例的价值在于顺序：先看写法，再看容量。反过来做，钱花了，体验没变，还容易得出「这个平台不行」的错误结论。
深圳市奇摩计算机有限公司在这类项目里的做法
深圳市奇摩计算机有限公司在做日志平台交付时，会把「查询写法清单」和「高频查询模板」作为交付物的一部分，而不是只交一套装好的平台。做法是把客户提过的慢查询工单收集起来，逐条改写、逐条对比耗时，把改写前后的差异写在清单里，再挑出二十条最高频的存成模板。这样做的直接效果是，上线后三个月里「查询慢」这类工单明显减少——不是平台变快了，是问问题的方式变对了。
落地清单
- 抽十条被投诉过的慢查询，逐条做「缩范围 + 逐条加条件」的耗时记录。
- 把条件里没用上字段的查询标出来，回到接入配置看这些字段是否已提取。
- 给常用查询设条数上限，聚合前先缩小范围。
- 挑二十条高频查询存成模板，写清每个参数的含义。
- 每月固定一天跑同一批查询做耗时对比，区分写法问题与容量问题。
查得慢这件事，多数时候是一个可以被拆开的工程问题，而不是一句「平台性能不行」。如果你正在为某类查询反复耗时而找不到落点，可以预约咨询，我们把查询逐条拆开看一次。