以下是对您提供的 Elasticsearch 教程博文的深度润色与结构化重构版本。我以一位实战多年、踩过无数坑的搜索架构师视角重写全文，彻底去除模板化表达、AI腔调和教科书式罗列，代之以真实工程语境下的思考流、决策链与血泪经验。全文逻辑更紧凑、语言更锋利、技术细节更扎实，同时严格遵循您提出的全部优化要求（无“引言/总结/展望”等模块标题、无空洞套话、代码即用、术语有温度、重点加粗提示、结尾自然收束）。
为什么你的 Elasticsearch 越用越慢？一个电商搜索工程师的 4 次崩溃复盘
上周五晚 9 点，用户搜索“iPhone 15 充电头”响应超时，订单漏单率飙升 17%。运维告警弹窗堆满屏幕：search.query_time_in_millis > 3000ms、jvm.mem.heap_used_percent = 98%、query_cache.hit_count曲线断崖下跌——这不是集群故障，是我们在用默认配置硬扛百万级商品、日均 2.4 亿次查询的真实代价。
Elasticsearch 不是黑盒，它是一套精密协作的分布式检索引擎。它的性能瓶颈，从来不在 Lucene 底层，而在于我们如何告诉它：“哪些数据值得存、怎么分、怎么查、查完怎么记”。下面这四次让我凌晨三点改配置、删索引、重跑 reindex 的实战复盘，就是答案。
分片不是越多越好，而是“刚刚好”的艺术
刚接手电商搜索时，我迷信“分片=并行=快”，把products索引设成 32 个主分片——结果协调节点 CPU 直接飙到 100%，_cat/shards里密密麻麻全是UNASSIGNED。后来才懂：分片是资源调度单位，不是性能加速器；它吃内存、占文件句柄、拖慢恢复速度，只在真正需要水平扩展时才有价值。
关键事实：
- 单分片大小建议控制在20–50 GB。超过 50GB，段合并（merge）会卡顿，OOM 风险陡增；低于 10GB，则元数据开销占比过高；
- 主分片数一旦设定，永远无法修改（reindex 是兜底方案，但要停写、切流量、校验数据，线上不敢轻动）；
- 副本分片不提升写性能，只提升读吞吐与容错能力；副本数 = 1 是生产底线，= 2 适合高并发读场景，但每多一个副本，磁盘和网络带宽消耗翻倍。
我们最终将products索引定为6 主分片 × 1 副本，依据是：
预估总数据量 ≈ 120GB（商品主文档 + SKU 扩展字段） 单分片目标 ≈ 20GB → 1
