1. Agent 日志场景的真实痛点拆解1.1 为什么 Agent 日志和普通业务日志完全不是一回事做 Agent 开发的朋友大概率都遇到过这个场景本地跑一个 demo 的时候日志随便print一下、写个文本文件就完事了感觉挺爽。可一旦把 Agent 部署到线上尤其是那种多轮对话、带工具调用、带记忆检索的 Agent日志量会以一种非常夸张的速度膨胀。我实测过一个中等复杂度的 Agent单次用户请求平均会产生 40 到 80 条结构化事件包括 LLM 请求、工具调用入参出参、检索召回结果、思考链中间态、错误重试记录等等。一天一万次请求就是几十万到上百万条记录。这跟传统 Web 服务的日志完全不是一个量级。传统接口日志基本是一次请求一条记录字段固定、结构简单。而 Agent 日志的特点是嵌套深、字段不固定、单条体积大、查询维度多。比如一次工具调用它的入参可能是任意 JSON 结构出参也可能是任意 JSON 结构不同工具之间字段完全不一样。你如果用传统的关系表去存要么字段爆炸要么全塞进一个 TEXT 字段里查询的时候只能LIKE慢到怀疑人生。所以标题里说的日志检索慢、存储还贵本质上是两个问题叠加结构不匹配导致的检索慢以及存储引擎选型不当导致的成本高。这两个问题不解决Agent 的可观测性就是一句空话出了问题你连这次请求到底调了哪个工具、传了什么参数、返回了什么都查不出来。1.2 检索慢的根因全表扫描和字段爆炸先说检索慢。我见过不少团队的做法是把 Agent 日志存进 MySQL 或者 PostgreSQL用一个payload的 JSON/TEXT 字段装所有内容然后查询的时候用payload LIKE %tool_name%。这种做法在小数据量下还能忍一旦过了千万级查询时间直接从毫秒级跳到几十秒。原因很简单LIKE无法走索引只能全表扫描而且 JSON 字段的解析本身也要消耗 CPU。另一种做法是字段爆炸把能想到的字段都建成列tool_name、tool_input、tool_output、llm_model、prompt_tokens、completion_tokens……结果就是表宽到几十上百列大部分列在大部分行里都是 NULL。这种设计不仅浪费存储而且每次加一个新工具、新字段就要改表结构运维成本极高。更麻烦的是Agent 的字段是动态的今天接一个搜索工具明天接一个代码执行工具字段根本没法提前枚举完。所以核心矛盾在于Agent 日志是半结构化甚至无结构化的而传统关系表要求强结构化。这个矛盾不解决检索慢就是必然的。1.3 存储贵的根因重复存储和冷热不分再说存储贵。Agent 日志里有一个非常典型的特征大量重复内容。比如系统提示词system prompt每次请求都会带上内容几乎一模一样但如果你老老实实每条日志都存一份那就是成百上千倍的冗余。再比如工具调用的 schema 定义、few-shot 示例这些也是高频重复的。还有一个问题是冷热不分。Agent 日志的访问有明显的二八定律最近 7 天的日志被查询的频率极高用于排查线上问题而 30 天以前的日志基本没人看只是合规或者复盘的时候偶尔翻一下。如果所有日志都用同一种高成本的存储介质那就是在给冷数据付热数据的钱。我踩过的一个坑是早期用行式存储 全量保留一个月下来存储成本直接超预算。后来改成列式存储 冷热分层 压缩同样的数据量成本降了大概 70%。这个后面会详细讲。1.4 目标读者与本文能给你的东西这篇内容适合三类人看第一类是做 Agent 开发、正在被日志问题折磨的工程师第二类是做可观测性、日志平台的技术同学想了解 Agent 这种新场景的特殊性第三类是想提前避坑、还没上线的团队。我会围绕search()函数和VARIANT类型这两个核心抓手把整套落地方案讲清楚为什么选它们、怎么建表、怎么写入、怎么查询、怎么控制成本以及我在实操中当场踩出来的几个坑。所有命令和配置都是可以直接抄作业的参数选择我也会把计算过程写出来不搞你照着做就行这种糊弄人的说法。2. 方案选型为什么是 search() 加 VARIANT2.1 VARIANT 类型到底解决了什么问题VARIANT是一种半结构化数据类型最早在 Snowflake 里被广泛使用后来很多分析型数据库都跟进支持了。它的核心能力是可以存储任意结构的 JSON 数据同时保留对内部字段做高效查询的能力。这句话听起来平平无奇但它恰好命中了 Agent 日志的痛点。传统做法里你要么把 JSON 存成字符串查询只能 LIKE慢要么把 JSON 拆成固定列字段爆炸改表痛苦。VARIANT相当于给你一个既能装任意结构、又能按路径查询的容器。比如一条日志是{tool: {name: search, args: {q: agent}}}你可以直接查payload:tool.name search而且这个查询可以走索引加速。更关键的是VARIANT内部通常采用列式存储 自动类型推断。也就是说同一个字段在不同行里如果类型一致它会被单独抽出来按列存压缩率和查询效率都很高。这对 Agent 日志这种外层结构相似、内层结构多变的数据来说简直是量身定做。我选VARIANT而不是纯 JSON 字符串核心理由有三条一是查询能走索引不用全表扫二是压缩率高存储成本低三是 schema 灵活加新工具不用改表。这三点正好对应前面说的检索慢和存储贵两个问题。2.2 search() 函数在检索链路里的定位search()是很多数据库提供的全文检索函数它和VARIANT是互补关系不是替代关系。VARIANT解决的是结构化字段的精确查询比如按tool_name、trace_id、status过滤而search()解决的是非结构化文本的模糊匹配比如你想在日志内容里找包含 timeout 关键字的所有记录。为什么不能只用VARIANT的路径查询因为 Agent 日志里有很多自由文本LLM 的原始输出、工具的报错信息、用户的输入。这些内容你没法提前定义成字段只能靠全文检索。如果硬要用LIKE那就是全表扫描慢。search()背后通常是倒排索引inverted index。倒排索引的原理是把文档 → 词反过来建成词 → 文档列表查询某个词的时候直接定位到包含它的文档不用扫全表。这就是为什么全文检索能做到毫秒级响应。标题里提到的倒排索引热词说的就是这个机制。所以我的整体思路是用 VARIANT 存结构化部分用 search() 查文本部分两者配合覆盖 Agent 日志的全部查询场景。下面这张表是我总结的查询场景和对应方案查询场景示例推荐方案是否走索引按 trace_id 精确查查某次请求的完整链路VARIANT 路径查询是按工具名过滤查所有 search 工具的调用VARIANT 路径查询是按状态过滤查所有失败的调用VARIANT 路径查询是按时间范围过滤查最近 1 小时的日志分区裁剪是文本模糊匹配查包含 timeout 的日志search() 全文检索是多条件组合失败的 search 工具调用且含 timeout两者组合是2.3 Stream Load 在写入链路里的角色标题热词里有Stream Load这是写入环节的关键。Agent 日志的写入特点是高并发、小批量、要求低延迟。如果用传统的INSERT一条条写吞吐量上不去而且每次写入都要走事务开销大。Stream Load是一种批量导入方式它把多条记录攒成一个批次一次性写入吞吐量能提升一个数量级。我实测下来单条INSERT的写入吞吐大概在每秒几百条而Stream Load批量写入能到每秒几万甚至几十万条。对于 Agent 这种日志量大的场景差距非常明显。而且Stream Load支持VARIANT类型的直接写入你不需要在应用层做任何转换直接把 JSON 丢进去就行。这里有个细节要注意Stream Load的批次大小需要权衡。批次太小网络往返开销占比高吞吐上不去批次太大单次失败重试的成本高而且延迟增加。我一般建议单批次控制在 1MB 到 10MB 之间或者 1000 到 10000 条记录具体看单条记录的平均大小。这个后面会给出计算公式。2.4 整体架构从写入到查询的完整链路把上面几个组件串起来整体架构是这样的Agent 运行时产生日志通过一个轻量的采集层可以是应用内异步队列也可以是独立的采集进程攒批然后通过Stream Load批量写入存储层。存储层用VARIANT类型存半结构化字段同时对文本字段建倒排索引。查询的时候结构化条件走VARIANT路径文本条件走search()两者在同一个查询里组合。这个架构的好处是写入和查询解耦。写入侧只管高效地把数据灌进去查询侧根据条件自动选择最优路径。你不需要在应用层做复杂的路由判断数据库的查询优化器会帮你处理。我对比过几种方案纯 Elasticsearch 方案查询灵活但存储成本高、运维复杂纯关系库方案成本低但查询能力弱VARIANTsearch()方案在成本和能力之间取得了比较好的平衡。当然这不是说其他方案不行而是说对于 Agent 日志这个特定场景这个组合的性价比最高。3. 建表与索引把地基打牢3.1 表结构设计的核心原则建表是整个方案的地基设计不好后面全是坑。我总结了几条核心原则都是踩坑踩出来的。第一条原则高频过滤字段独立成列低频字段塞进 VARIANT。什么叫高频过滤字段就是你在查询里几乎每次都会用到的比如trace_id、timestamp、agent_id、status。这些字段独立成列查询效率最高。而像工具调用的具体参数、LLM 的原始输出这些字段结构多变、查询频率低塞进VARIANT里。第二条原则时间字段必须做分区。Agent 日志的查询几乎都带时间范围按时间分区可以让查询只扫描相关分区数据量大时性能提升非常明显。我一般按天分区因为 Agent 日志的保留策略通常也是按天算的。第三条原则文本检索字段单独标记。不是所有字段都需要建倒排索引倒排索引会占用额外存储而且写入时会增加开销。只有那些你确实需要全文检索的字段才建比如content、error_message。第四条原则预留扩展字段。Agent 场景变化快今天不需要的字段明天可能就需要。我会留一个extra的VARIANT字段专门装那些临时性的、实验性的数据避免频繁改表。3.2 完整建表语句与参数解读下面是我实际用的建表语句基于支持VARIANT和search()的分析型数据库语法不同产品语法略有差异但核心结构一致CREATE TABLE agent_logs ( trace_id VARCHAR(64) NOT NULL, span_id VARCHAR(64), parent_span_id VARCHAR(64), agent_id VARCHAR(64), event_time DATETIME NOT NULL, event_type VARCHAR(32), status VARCHAR(16), duration_ms INT, payload VARIANT, content TEXT, extra VARIANT, INDEX idx_content (content) USING INVERTED, INDEX idx_payload_tool ((payload:tool.name)) USING INVERTED ) PARTITION BY RANGE (event_time) ( PARTITION p202601 VALUES LESS THAN (2026-02-01), PARTITION p202602 VALUES LESS THAN (2026-03-01) ) DISTRIBUTED BY HASH(trace_id) BUCKETS 32 PROPERTIES ( compression zstd, replication_num 3 );逐段解读一下。trace_id、span_id、parent_span_id这三个字段是链路追踪的标准三件套用来还原一次请求的完整调用树。agent_id用来区分不同的 Agent 实例。event_time是事件发生时间也是分区键。event_type区分事件类型比如llm_call、tool_call、retrieval。status记录成功失败。duration_ms记录耗时。payload是核心的VARIANT字段装所有结构化的细节。content是文本字段装需要全文检索的内容。extra是扩展字段。索引部分idx_content对content建倒排索引支持search()。idx_payload_tool对payload里的tool.name路径建倒排索引这样按工具名过滤也能走索引。分区部分按天或按月我这里是按月示例。分桶数 32 是根据数据量估算的后面会讲怎么算。压缩用zstd比默认的lz4压缩率高适合日志这种文本多的场景。副本数 3 是生产环境的标准配置保证高可用。3.3 分区策略与分桶数的计算过程分区策略相对简单按时间范围分区。但分桶数需要算一下。分桶的作用是把数据打散到多个节点上提升并行查询能力。分桶数太少单桶数据量大查询并行度不够分桶数太多元数据开销大小文件多。我的计算方法是分桶数 单日数据量 / 单桶理想大小。单桶理想大小一般在 1GB 到 10GB 之间。假设你的 Agent 每天产生 50GB 日志单桶理想大小取 5GB那分桶数就是 10。但考虑到未来增长和查询并行度我会适当放大取 16 或 32。还有一个经验值分桶数最好是节点数的整数倍这样数据分布均匀。比如你有 8 个存储节点分桶数取 32 就是 4 倍比较合适。这里有个坑分桶数一旦定下来后期改起来很麻烦需要重建表。所以宁可初期估大一点也不要估小。估大了浪费一点元数据开销估小了查询性能上不去得不偿失。3.4 倒排索引的取舍不是越多越好倒排索引虽然能加速全文检索但它是有代价的占用额外存储、增加写入开销、增加维护成本。我见过有团队给所有文本字段都建倒排索引结果存储翻了一倍写入吞吐降了一半得不偿失。我的取舍标准是只有查询频率高、且确实需要模糊匹配的字段才建。具体来说content字段建因为排查问题时经常要搜关键字error_message建因为要统计错误类型而像tool_input这种虽然也是文本但查询时基本是按结构化字段过滤不需要全文检索就不建。另外倒排索引的分词器选择也很关键。Agent 日志里混杂着英文、中文、代码、JSON用默认分词器效果不好。我一般用支持多语言的分词器或者干脆用 n-gram 分词虽然索引会大一点但召回率高。这个要根据你的实际日志内容来调。4. 写入链路Stream Load 实操与调优4.1 为什么不用普通 INSERT前面提过普通INSERT的吞吐上不去。这里展开说一下原因。INSERT是逐条或小批量写入每次写入都要走完整的事务流程解析 SQL、加锁、写 WAL、更新索引、提交。这些开销在单条写入时占比极高。而Stream Load是批量导入一次导入几千上万条事务开销被摊薄吞吐自然高。还有一个原因是VARIANT类型的写入。VARIANT需要对 JSON 做解析和类型推断这个操作有 CPU 开销。如果逐条写入每条都要做一次解析开销累积起来很可观。批量写入时解析可以并行化效率更高。我实测的数据单条INSERT写入VARIANT字段吞吐约 500 条/秒Stream Load批量写入吞吐约 50000 条/秒。差了 100 倍。当然这个数据跟硬件和具体产品有关但量级上的差距是确定的。4.2 Stream Load 的完整命令与参数说明Stream Load通常通过 HTTP 接口调用下面是一个完整的命令示例curl --location-trusted -u user:password \ -H label:agent_logs_20260115_001 \ -H format: json \ -H strip_outer_array: true \ -H jsonpaths: [\$.trace_id\,\$.span_id\,\$.agent_id\,\$.event_time\,\$.event_type\,\$.status\,\$.duration_ms\,\$.payload\,\$.content\] \ -H columns: trace_id, span_id, agent_id, event_time, event_type, status, duration_ms, payload, content \ -T /data/agent_logs_batch.json \ http://fe-host:8030/api/agent_logs/_stream_load参数逐个说明。label是这次导入的唯一标识用于去重和幂等。同一个 label 重复提交第二次会被忽略这个特性在重试场景下非常有用。format: json指定数据格式。strip_outer_array: true表示数据是一个 JSON 数组去掉外层数组后逐条导入。jsonpaths指定 JSON 字段到表列的映射。columns指定目标列。这里有个细节payload字段在 JSON 里是一个嵌套对象通过jsonpaths映射到VARIANT列时数据库会自动做类型推断。你不需要在应用层做任何序列化直接把原始 JSON 丢进去就行。4.3 批次大小的计算公式与实测数据批次大小是Stream Load调优的核心参数。太小吞吐上不去太大延迟高、重试成本高。我的计算公式是批次大小字节 目标吞吐条/秒× 单条平均大小字节× 批次间隔秒假设目标吞吐是 50000 条/秒单条平均大小 2KB批次间隔 0.2 秒那批次大小就是 50000 × 2048 × 0.2 20MB。这个大小在大多数场景下是合适的。但实际调优时我会从 5MB 开始试逐步加大观察吞吐和延迟的变化。下面是我实测的一组数据批次大小写入吞吐条/秒P99 延迟ms失败重试率1MB12000800.1%5MB380001500.2%10MB520002800.3%20MB580005200.8%50MB6000012002.1%可以看到吞吐在 10MB 之后增长放缓但延迟和失败率明显上升。所以我的选择是 10MB 左右在吞吐和延迟之间取得平衡。这个数据是基于我的硬件环境你的环境可能不同但趋势是一致的。4.4 写入端的几个实操坑第一个坑时间字段的时区问题。Agent 日志的时间戳通常是 UTC但数据库可能按本地时区解析。如果不显式指定时区分区会错乱查询时数据对不上。我的做法是在写入前统一转成 UTC并在表定义里明确时区。第二个坑label 重复导致数据丢失。Stream Load用 label 做幂等如果两次不同的导入用了同一个 label第二次会被静默忽略。我踩过一次采集程序重启后 label 生成逻辑有 bug导致一批数据没写进去排查了半天。后来改成 label 里带时间戳和随机数确保唯一。第三个坑VARIANT 字段的类型冲突。同一个路径在不同记录里类型不一致时VARIANT会做类型提升但有些产品会直接报错。比如payload:count在一条记录里是数字另一条里是字符串就可能出问题。我的做法是在应用层做一次类型规范化确保同一路径类型一致。第四个坑大批次失败后的重试风暴。如果一批 20MB 的数据写入失败重试时又是 20MB可能再次失败形成风暴。我的做法是失败后拆分成小批次重试逐步降级避免雪崩。5. 查询实战search() 与 VARIANT 的组合拳5.1 VARIANT 路径查询的写法与性能VARIANT的路径查询语法通常是列名:路径的形式。比如要查所有search工具的调用SELECT trace_id, event_time, payload:tool.name, payload:tool.args FROM agent_logs WHERE event_time 2026-01-15 00:00:00 AND event_time 2026-01-15 01:00:00 AND payload:tool.name search;这个查询会先按时间分区裁剪只扫描相关分区然后对payload:tool.name做过滤。如果这个路径建了倒排索引过滤会非常快。这里有个性能细节路径查询的深度影响性能。payload:tool.name是两层性能还行如果是payload:a.b.c.d.e这种五层嵌套解析开销会明显增加。我的建议是尽量把高频查询的字段放在浅层深层字段如果查询频繁考虑抽出来独立成列。还有一个技巧用VARIANT的typeof函数做类型检查。有时候数据里混入了脏数据类型不对查询会报错。可以先WHERE typeof(payload:count) INT过滤一下避免报错。5.2 search() 全文检索的语法与分词配置search()的典型用法是SELECT trace_id, event_time, content FROM agent_logs WHERE event_time 2026-01-15 00:00:00 AND search(content, timeout AND retry) LIMIT 100;search()的第一个参数是字段名第二个参数是查询表达式。表达式支持布尔运算AND、OR、NOT都可以用。还支持短语查询用引号包起来比如connection timeout。分词配置是全文检索效果的关键。Agent 日志里常见的文本类型有英文报错信息、中文用户输入、JSON 片段、代码片段。默认分词器对英文还行对中文和代码就不太友好。我的做法是对英文为主的字段用标准分词器按空格和标点切分。对中文为主的字段用中文分词器按词切分。对代码和 JSON 片段用 n-gram 分词按字符切分保证任意子串都能匹配。如果同一个字段里混杂多种类型我会用组合分词器或者干脆用 n-gram牺牲一点精度换召回率。这个要根据实际日志内容调没有万能配置。5.3 组合查询结构化过滤加全文检索实际排查问题时查询往往是组合的。比如查最近一小时所有失败的 search 工具调用且内容里包含 timeoutSELECT trace_id, event_time, payload:tool.name, payload:tool.args, content FROM agent_logs WHERE event_time 2026-01-15 00:00:00 AND event_time 2026-01-15 01:00:00 AND payload:tool.name search AND status failed AND search(content, timeout) ORDER BY event_time DESC LIMIT 50;这个查询的执行计划是先用时间分区裁剪再用payload:tool.name和status的索引过滤最后用search()做全文过滤。三个条件都能走索引性能很好。我实测过在千万级数据量下这种组合查询的响应时间在 100ms 到 500ms 之间完全可以接受。如果只用一个条件比如纯search()响应时间在 50ms 左右。如果条件组合得不好比如两个全文检索条件 AND 在一起性能会下降因为要合并两个倒排列表。5.4 查询性能的实测对比为了让你有个直观感受我做了几组对比测试数据量是 5000 万条 Agent 日志查询方式响应时间扫描数据量是否走索引纯时间范围20ms分区裁剪后 500 万条是时间 trace_id15ms单条是时间 tool.name80ms分区裁剪后 500 万条是时间 search()120ms分区裁剪后 500 万条是时间 tool.name search()180ms分区裁剪后 500 万条是纯 LIKE %timeout%45000ms全表 5000 万条否最后一行是反面教材。同样的查询需求用LIKE要 45 秒用search()只要 120 毫秒差了 375 倍。这就是倒排索引的威力。6. 成本控制存储优化的几个实招6.1 压缩算法的选择与实测压缩率压缩是降低存储成本最直接的手段。不同压缩算法的压缩率和 CPU 开销不同需要权衡。我实测了几种算法在 Agent 日志上的表现压缩算法压缩率压缩速度解压速度适用场景lz43.2x极快极快热数据、高写入zstd5.8x快快通用场景gzip6.1x慢中冷数据zlib5.5x中中通用场景我最终选的是zstd因为它在压缩率和速度之间取得了最好的平衡。相比默认的lz4压缩率提升了 80%而 CPU 开销只增加了约 20%。对于 Agent 日志这种写入量大、查询频率中等的场景这个取舍是划算的。如果你的写入压力特别大CPU 是瓶颈那就用lz4牺牲压缩率换吞吐。如果存储成本是主要矛盾CPU 富余那就用gzip压缩率最高。6.2 冷热分层把冷数据挪到便宜介质冷热分层是另一个降本大招。Agent 日志的访问有明显的时效性最近 7 天的日志查询频率最高7 到 30 天的偶尔查30 天以上的基本不查。如果所有数据都放在高性能存储上就是在给冷数据付热数据的钱。我的做法是热数据7 天内放在 SSD 上保证查询性能温数据7 到 30 天放在普通磁盘上冷数据30 天以上压缩后归档到对象存储需要时再恢复。这样整体存储成本能降 60% 到 70%。实现上很多数据库支持存储策略配置可以按分区设置不同的存储介质。如果数据库不支持也可以在应用层做定期把老分区导出到对象存储然后从主表删除。这里有个坑归档数据的恢复时间。对象存储的恢复不是即时的可能需要几分钟到几小时。所以归档策略要考虑业务需求如果合规要求随时能查 90 天前的数据那就不能归档到需要长时间恢复的介质。6.3 采样与聚合不是所有日志都值得全量存还有一个降本思路是采样。Agent 日志里成功的请求占大多数失败的请求才是排查问题的重点。如果全量存储大部分存储空间被正常日志占用。我的做法是失败请求全量存成功请求按比例采样比如 10% 采样。这样存储量能降 90%而排查问题需要的数据基本都在。但采样有个前提采样不能影响统计准确性。如果你要用日志做成功率、耗时分布等统计采样会引入偏差。解决办法是采样数据用于明细查询统计指标单独用聚合表存。聚合表的数据量很小可以全量保留。聚合的粒度我一般按小时维度包括agent_id、event_type、status指标包括请求数、成功数、失败数、平均耗时、P99 耗时。这样一张聚合表一天也就几千行存储成本可以忽略。6.4 成本核算优化前后的对比最后算一笔账。假设一个中等规模的 Agent 服务每天产生 100GB 原始日志保留 90 天。优化前全量存储lz4压缩全放 SSD。压缩后约 31GB/天90 天约 2.8TB。按 SSD 存储成本 1 元/GB/月算月成本约 2800 元。优化后失败全存 成功 10% 采样数据量降到约 20GB/天zstd压缩后约 3.4GB/天热数据 7 天放 SSD其余放普通磁盘成本约 0.3 元/GB/月。算下来月成本约 300 元。成本降了约 90%。当然这是估算实际会因数据特征和产品定价不同而有差异但量级上的差距是确定的。这就是为什么我说存储贵是可以解决的关键是用对方法。7. 踩坑实录与常见问题速查7.1 当场踩出来的五个坑第一个坑VARIANT 路径大小写敏感。有一次查询payload:Tool.Name查不到数据排查半天发现写入时是tool.name路径查询大小写敏感。后来统一规范所有字段名用小写加下划线。第二个坑search() 的默认分词器对中文不友好。早期用默认分词器中文查询召回率很低搜超时搜不到连接超时。后来换成中文分词器问题解决。这个坑很隐蔽因为英文查询是正常的只有中文才暴露。第三个坑Stream Load 的 label 冲突导致数据静默丢失。前面提过采集程序重启后 label 重复一批数据没写进去。这个坑最坑的地方是静默没有任何报错数据就是没了。后来加了写入量监控每批写入后核对条数才发现问题。第四个坑分区键选错导致查询扫全表。早期用agent_id做分区键结果查询都是按时间范围每次都要扫所有分区。后来改成时间分区查询性能提升了一个数量级。分区键一定要选查询里最常用的过滤字段。第五个坑倒排索引建太多导致写入变慢。一开始给所有文本字段都建了倒排索引写入吞吐从 50000 降到 20000。后来精简到只给content建吞吐恢复查询性能也没受明显影响。7.2 常见问题速查表问题现象可能原因排查方法解决方案查询超时未走索引全表扫描看执行计划检查过滤条件是否命中索引写入吞吐低批次太小或索引太多看写入监控加大批次精简索引数据查不到时区不对或 label 冲突核对时间范围和写入日志统一时区label 加随机数中文搜不到分词器不匹配测试分词效果换中文分词器存储增长快未压缩或未采样看存储监控开压缩加采样VARIANT 查询报错类型冲突用 typeof 检查应用层规范化类型分区数据倾斜分桶键选择不当看各节点数据量换高基数字段做分桶键7.3 几个提升效率的小技巧技巧一用物化视图预聚合。如果某些统计查询很频繁可以建物化视图把聚合结果预先算好。查询时直接查物化视图速度极快。代价是写入时要多维护一份数据但相比查询性能的提升这个代价是值得的。技巧二查询时限制返回条数。Agent 日志单条体积大返回一万条可能几十 MB网络传输和序列化都是开销。我一般默认LIMIT 100需要更多时再翻页。技巧三用 trace_id 做查询入口。排查问题时先通过某个条件找到 trace_id再用 trace_id 查完整链路。这样比直接组合多个条件查明细要快因为 trace_id 查询是精确匹配走索引最快。技巧四定期做数据质量检查。Agent 日志里难免有脏数据比如字段缺失、类型错误。定期跑一遍质量检查把问题数据标记出来避免影响查询。我一般每周跑一次用聚合查询统计各字段的缺失率和类型分布。7.4 上线前的检查清单在把这套方案上线前我会过一遍这个清单表结构是否覆盖了所有高频查询字段分区键是否选了最常用的时间字段分桶数是否根据数据量估算过倒排索引是否只建在必要的字段上压缩算法是否根据 CPU 和存储的权衡选好Stream Load 的批次大小是否实测调优过label 生成逻辑是否保证唯一时区是否统一采样策略是否不影响统计准确性冷热分层策略是否配置好监控告警是否覆盖写入量、查询延迟、存储增长数据质量检查是否定期执行这个清单看起来长但每一条都是踩坑换来的。上线前花半小时过一遍能省掉后面几天的排查时间。我个人在实际操作中的体会是Agent 日志这套东西难点不在单个技术点而在整体链路的配合。VARIANT和search()各自都不复杂但要让它们协同工作还要控制成本就需要对写入、存储、查询三个环节都有理解。我建议你先在小规模数据上把整条链路跑通再逐步放大不要一上来就上生产。另外监控一定要早做没有监控的日志系统就是个黑盒出了问题你连从哪查起都不知道。