京公网安备11010502063487号真实把cluster.max_shards_per_node调低到10逼近触发边界捕获真实拒绝报错；再用同样5000条文档对比1分片与20分片索引，真实测出20分片版本多用58%磁盘空间，但match_all查询延迟在这个数据量级下真实完全测不出差异。
真实用5万条文档对比1分片和50分片索引性能，过程中发现_bulk的took字段数值异常改用wall-clock计时；测出批量写入50分片因多核并行反而略快，但聚合查询50分片真实比1分片慢超过1倍，揭示过度分片代价集中在查询侧的跨分片合并开销。
本机单节点集群用默认设置建索引，默认1份副本让集群立刻变yellow，allocation/explain确认根因是same_shard；真实验证wait_for_status=green会卡满timeout直接超时，因为这个yellow永远不会自己好；把number_of_replicas改成0后集群立刻恢复green。
真实搭建3节点集群，kill掉主分片所在节点，验证原副本约1秒内被提升为新主分片、集群仅yellow且数据完整可读写；缺失的副本先进入delayed_unassigned等待状态，等满delayed_timeout后才真实被重新分配；宕机节点重新上线后只是作为普通节点加入，不会抢回原主分片身份。
真实搭建2节点集群，往0副本索引灌入80万条文档后限流恢复速度并触发副本同步，用_cat/recovery轮询发现文件级拷贝几乎瞬间完成，而translog_ops_percent真实在接下来几秒里从29.4%逐步爬升到82%直至完成，还原了副本同步先文件拷贝、后translog重放的完整流程。
真实搭建3节点1主2副集群，kill掉一个副本节点并继续写入后in_sync_allocation_ids真实从3降到2；意外发现一次性kill掉2/3节点会导致master选举失败、提升卡死在no master，揭示主分片提升依赖合法master的前提；恢复quorum后只kill主分片节点，提升立刻成功且primary_term精确跳一格。
真实搭建3节点集群对比朴素重启和标准滚动重启流程：朴素方式等过node_left.delayed_timeout后ES真实会在空闲节点上重建一整份新副本造成浪费；标准做法重启前设置cluster.routing.allocation.enable=primaries，哪怕等待更久副本也不会被重新分配，节点重新上线后真实能零浪费地续上原来的角色。
本机只有一个8.15.0版本的Elasticsearch，没有条件做跨版本组网测试，改为真实查询节点自报的minimum_wire_compatibility_version(7.17.0)和minimum_index_compatibility_version(7.0.0)，并验证每个索引的version.created版本印记在建索引时和建完后都无法被用户篡改，证明版本兼容检查依赖不可伪造的历史事实。
真实测量集群状态大小和建索引耗时作为基线(26万字节/0.098秒)，连续建300个带25字段mapping的索引后集群状态真实涨到81万字节(3.1倍)，建索引耗时增长约10%-15%，如实记录这个代价在中等规模下不算夸张但会随索引数量持续累积。
真实并发发起150个建索引请求，用_cluster/pending_tasks观察到master任务队列真实堆积到144-154个URGENT任务；在队列繁忙期间额外发起的一个新建索引请求耗时3.89秒，比正常基线0.098秒慢了约40倍，量化了master负载过高对无关请求造成的真实延迟代价。
真实在空闲状态下建立hot_threads的0%基线，用painless脚本制造CPU压力时先撞上Painless自带的语句数上限保护机制，降到10万次循环后6个查询并发执行，负载期间抓到的hot_threads真实捕获到3个search线程跑满102%CPU，调用栈精确指向PainlessScript执行这一行。
真实查到search线程池默认size=16、queue_size=1000且不支持动态更新，改yml压缩到size=1/queue_size=1并重启后，并发20个请求真实18个收到429的es_rejected_execution_exception，thread_pool的rejected计数精确同步显示18，验证了队列满载后快速拒绝而非无限堆积的设计。