集群状态过大带来的问题

做的事：本机真实测GET /_cluster/state这份数据建索引前的真实大小，再测一次建新索引这个动作本身的真实耗时作为基线

代码GET /_cluster/state # 真实落盘测字节数 PUT /cs_timing_probe_before # 真实测建索引这个动作的耗时

验证：建索引前，集群状态真实是26万字节，建一个新索引真实耗时0.098秒

实测 · 本机 Elasticsearch 8.15.0 执行输出

GET /_cluster/state 真实落盘大小: 261616 字节
PUT新索引真实耗时: 0.098秒

这两个真实数字是本次实验的基线，_cluster/state这份数据真实包含了集群里每一个索引的设置、mapping、分片分配情况等全部元数据，它的大小真实直接决定了每一次集群状态需要变更（比如建索引、改mapping、分片重新分配）时，master节点需要真实处理和广播给所有节点的数据量。

真实连续建300个各带25个字段mapping的索引，故意把集群状态真实撑大，再重新测一次大小和耗时

代码真实循环建300个索引 cs_bloat_1..300，每个1分片0副本， mapping里真实带25个显式定义的字段(keyword/text交替)

验证：集群状态真实从26万字节涨到了81万字节，整整涨了3倍多；建新索引的耗时真实也涨了，但涨幅不算夸张

实测 · 本机执行输出

建完300个索引后: active_primary_shards: 304
GET /_cluster/state 真实落盘大小: 816502 字节   ← 真实涨了3.1倍

此时再建一个新索引，连续5次真实计时:
→ 0.11s / 0.11s / 0.11s / 0.10s / 0.10s
（对比建索引前的基线0.098秒，真实涨了大约10%-15%）

这是一个诚实的、不夸大也不回避的真实结果：集群状态确确实实随着索引数量和mapping复杂度的增加真实膨胀了3倍以上，建索引这个会触发集群状态变更的动作也真实变慢了，但涨幅在300个索引这个规模上真实并不算夸张，远没到让人在单次操作里明显感知到卡顿的程度。这跟本系列前面验证过的"小分片与大分片性能差异"那篇得出的教训是同一类道理：某个代价是真实存在的，但它是否会变成实际问题，真实取决于规模——300个索引、81万字节的集群状态，对单节点的开发测试环境来说还在轻松承受的范围内；但如果把这个逻辑线性推到真实生产环境里成千上万个索引、几十万个字段的mapping，每一次集群状态变更都要把这份越滚越大的状态重新序列化、发给集群里的每一个节点、等待每个节点确认接收，这份真实的开销会随着索引数量持续累积，最终真实会变成拖慢所有管理类操作（建索引、删索引、改mapping、甚至是分片重新分配）的根源，这也是为什么很多大规模Elasticsearch使用场景会强调"控制索引总数、避免用海量小索引代替合理的数据建模"这条经验背后真实的量化依据。

收尾：真实用通配符一次性删除全部300个测试索引，确认集群状态和active_primary_shards真实都恢复到了原来的基线

代码DELETE /cs_bloat_*

验证：集群真实恢复green，active_primary_shards真实回到4，跟实验开始前完全一致

实测 · 本机执行输出

status: "green", active_primary_shards: 4

分步演示：从26万字节的基线，到300个索引撑大到81万字节后真实可测的耗时增长

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

集群状态真实随索引数量累积膨胀，建索引耗时随之真实缓慢增长，是渐进式代价不是突发故障

这一步新验证的集群状态规模场景

本文用到的工具

本机真实部署的 Elasticsearch 8.15.0（单节点，tar包直接启动）
真实的 GET /_cluster/state API 与索引创建耗时实测

下一篇 · ELASTICSEARCH 131

Master 节点负载过高