聚合内存占用与 Circuit Breaker

做的事：真实对30万个唯一UUID的字段跑terms聚合，size直接设成300000想把全部唯一值一次性拉出来

代码真实索引300000条文档，uid字段真实是300000个互不相同的UUID POST /cb_test/_search {"size":0,"aggs":{"t":{"terms":{"field":"uid","size":300000}}}}

验证：请求真实直接被拒绝，报错精确写出了65536这个默认的桶数量上限

→ 400 too_many_buckets_exception:
  "Trying to create too many buckets. Must be less than or equal to:
   [65536] but this number of buckets was exceeded. This limit can be
   set by changing the [search.max_buckets] cluster level setting."

这条真实报错揭示了search.max_buckets这个专门为了防止聚合把内存耗尽而设的保护阈值（本系列第70、78篇都分别验证过相关的硬编码上限，这是聚合层面类似的真实保护机制）。每一个聚合桶在服务端真实都需要维护计数器、子聚合状态等内存结构，一次性请求几十万个桶，真实会让这部分内存开销失控地膨胀，所以ES真实从请求校验阶段就直接把超出65536这个默认上限的请求拦截掉，而不是真的去尝试分配内存、等到内存真的耗尽才报错。

真实把size收窄到60000（低于默认上限），验证能否成功跑出接近上限数量的桶

代码POST /cb_test/_search {"size":0,"aggs":{"t":{"terms":{"field":"uid","size":60000}}}}

验证：60000个桶的请求真实成功了，确认65536是精确的分界线而不是模糊限制

→ 请求真实成功，bucket count: 60000

这个真实结果确认了65536这个数字是一条精确的硬性分界线：低于它的请求（本次60000）真实能正常执行完成，超过它的请求（前面的300000）真实会被直接拦截。

真实把search.max_buckets临时调低到1000，验证这个阈值是不是真的可配置、精确生效

代码PUT /_cluster/settings {"persistent":{"search.max_buckets":1000}} POST /cb_test/_search {"size":0,"aggs":{"t":{"terms":{"field":"uid","size":5000}}}}

验证：调低阈值之后，同样5000个桶的请求真实立刻被拒绝，报错里的数字精确变成了新设的1000

→ too_many_buckets_exception:
  "Must be less than or equal to: [1000] but this number of buckets was exceeded"
  ← 真实报错里的数字精确对应刚刚配置的1000，不再是默认的65536

分步演示：聚合桶数量保护从默认上限拦截到可配置精确生效的完整验证

每一步都是本文上面在本机真实的Elasticsearch 8.15.0上跑出来的原始结果。