ES日志查询需用multi_match替代多个orWhere，配合字段权重、分词预处理、bool查询规范及动态索引名，才能准、快、全。
直接用 where + 多个 orWhere 在日志表里查关键词，基本查不准、性能差、还漏结果——ES 不是数据库，得按它的语义来组织查询。
用 multi_match 替代手写多个 should 条件
很多人把 ES 当成 SQL 写，比如对日志的 message、level、service_name 字段分别加 termQuery 或 matchQuery，再塞进 bool.should。这会导致：匹配权重混乱、无法控制字段优先级、短词（如 “ERR”）容易误匹配整行。
正确做法是用 multi_match，它原生支持跨字段打分和策略选择：
-
type: "best_fields"：适合“找最相关字段”，比如用户输入"timeout ERR redis"，优先命中message里含完整短语的文档 -
type: "cross_fields"：适合拆词后分散匹配，比如姓名存为fname/lname，用户搜"john smith"可能出现在任一字段 - 显式指定
fields和权重，例如["message^3", "level^2", "service_name"]，避免无关字段拉低相关性
日志场景必须处理的三个预处理环节
原始日志文本（尤其 message）不清洗就扔给 ES，multi_match 效果会断崖下跌：
- 日志时间戳、进程 ID、堆栈缩进等噪声需在索引前剥离（用 Logstash 过滤器或 Laravel 的
toSearchableArray()中正则清理） - 中文日志必须配好分词器：
ik_max_word或jieba，否则"数据库连接失败"被切为单字，查"连接"就崩 - 错误码类字段（如
"ECONNREFUSED"、"500"）建议映射为keyword类型，再用terms查询精确过滤，别走全文分析流程
bool 查询里 must 和 should 的混用陷阱
查日志常要“必须含 ERROR 级别 + 可能含 timeout 或 redis 关键词”，这时容易错写成：
bool: {
must: [{ term: { level: "ERROR" } }],
should: [
{ match: { message: "timeout" } },
{ match: { message: "redis" } }
]
}
问题在于：ES 默认要求 should 至少满足一个，但没强制打分排序；更糟的是，如果只设 should 不设 minimum_should_match，部分低相关文档可能被顶到前面。
稳妥写法：
- 把确定性过滤（如时间范围、level、service_name）全放
must - 把模糊关键词放
should，并加"minimum_should_match": 1 - 若想让含两个关键词的文档排更高，用
"boost": 2给第二个match加权
Laravel Scout 集成时绕不开的 searchableAs() 动态索引名
日志按天分索引（如 logs-2026.08.12、logs-2026.08.13）是常态，但 Scout 默认只认固定索引名。硬编码会导致查不到当天日志，或扫全量历史索引拖慢响应。
解决方法是在模型里重写 searchableAs()：
public function searchableAs()
{
return 'logs-' . now()->format('Y.m.d');
}
注意两点：
- 这个函数每次查询都执行，别在里面做耗时操作（如 DB 查询）
- 跨多天检索时，不能只靠这个——得用索引通配符（如
logs-2026.08.*），并在 Scout 配置中启用indices.allow_multiple_indices: true（ES 7+ 默认开启）
真正难的不是写对一个查询，而是让 message 字段的分词结果和你心里想搜的词对得上；调错一次 analyzer，后面所有 multi_match 都白搭。
