聚合结果太大导致超时，应改用多次轻量查询替代重型聚合：先用terms取top N bucket key（如size:100），再对每个key单独发term filter+子聚合请求，客户端汇总；禁用track_total_hits和启用terminate_after，并确保聚合字段为keyword类型。
聚合结果太大导致超时，怎么拆分
直接对百万级文档做 terms + sum 嵌套聚合，ES 协调节点要合并所有 shard 的中间结果，内存和网络开销爆炸，常见表现是请求卡住、返回 search_phase_execution_exception 或超时（timeout 错误）。拆分不是“把一个聚合切成两段”，而是换思路：用多次轻量查询替代一次重型聚合。
- 先用
terms聚合取 top N 的 bucket key（比如前 100 个 category_id），带上size参数控制返回数量 - 再对每个 key 单独发请求，用
termfilter + 其他子聚合（如avg、stats）精确计算 - 客户端做最终汇总，避免 ES 合并压力。注意加
track_total_hits: false和terminate_after防止扫描全量
为什么不能用 chunkById 做 ES 聚合分页
chunkById 是 Laravel 对 MySQL 的分页封装，底层靠 id > ? ORDER BY id LIMIT N 实现。ES 没有自增主键语义，_id 是字符串且无序，强行模拟会导致漏数据或重复；更关键的是，聚合本身不产生“行式结果集”，它输出的是结构化桶（bucket），不存在可线性切分的 ID 序列。
- ES 的聚合结果是树状结构，不是平面列表，
from/size只对 hits 有效，对aggs无效 - 想“分页看聚合结果”，唯一合法方式是用
composite聚合——它支持after参数续查，但只支持terms、date_histogram等有限类型 - 若必须分批，优先选
composite+sources定义排序字段（如{"category_id": {"order": "asc"}}），别碰terms的collect_mode魔改
聚合字段类型写错，性能会差十倍
对 text 字段做 terms 聚合，ES 必须反向还原分词器输出的所有 term，再归并去重，CPU 占用飙升。实际项目里，90% 的慢聚合都源于 mapping 设计失误。
- 检查字段类型：
GET /your_index/_mapping，确认聚合字段是"type": "keyword"，不是"text" - 如果已有数据是
text，别改 mapping —— ES 不允许修改已存在字段类型。重建索引时显式定义fields: { raw: { type: "keyword" } }，然后聚合走field.keyword或field.raw - 电商类目路径（如
"1-2-5-"）这类字段，用prefix查询没问题，但聚合必须用keyword类型 +terms，不能用match_phrase_prefix
协调节点瓶颈在哪儿，怎么压
聚合慢常被误认为是数据节点 CPU 高，其实瓶颈往往在协调节点：它要接收所有 shard 的中间结果（可能几百 MB）、解析 JSON、合并桶、排序、截断，最后序列化返回。单次聚合返回 10000 个 bucket 就足以让协调节点 OOM。
- 强制限制
size：哪怕业务需要 Top 1000，也设成size: 1000，别留默认值（默认是 10） - 关掉不必要的统计：去掉
extended_stats改用stats，禁用show_term_doc_count_error - 用
filter替代must做前置筛选，让参与聚合的数据量从 100 万降到 1 万，效果比调优 DSL 强十倍
真正难的不是写对 DSL，而是判断哪些聚合该放 ES 做、哪些该挪到应用层——比如按用户维度的销售统计，不如在写入时用 pipeline 计算好存进 user_summary 索引，查的时候直接 term 拿。
