适用读者：要给 ES 定分片数、或排查"集群黄/红"的人。
前置：S13-J01。
实测环境：ES 8.15.3 单节点（2026-11-05）。
覆盖旧文：1574(297) = 297 点。
覆盖扩展：E-S13-007（分片容量）、E-S13-008（选举与脑裂）。
上一篇：S13-J01 · 索引调优：mapping、refresh、段合并
下一篇：S13-J03 · 检索性能优化。
1. 一句话结论
分片是"索引的最小并行单位"：分片太少不能并行，分片太多则元数据与开销爆炸。经验值：单分片 10–50 GB。
实测（单节点）：
status: green number_of_nodes: 1 active_primary_shards: 1
articles 0 p STARTED
（prirep=p 表示这是主分片；单节点下没有副本 → 节点挂了数据就没了。）
2. 分片与副本的基本规则
| 概念 | 说明 |
|---|---|
| 主分片（primary） | 建索引时定，不可改 |
| 副本（replica） | 可动态调 |
| 路由 | shard = hash(_routing) % 主分片数 |
"为什么主分片数不可改"：路由公式依赖它——改了会导致所有文档重新分布（要 reindex）。
实测（健康检查）：
_cluster/health → status/green, number_of_nodes/1, active_primary_shards/1
3. 分片数怎么定（E-S13-007）
分片数 ≈ 数据总量 ÷ (10–50 GB)
| 规模 | 建议 |
|---|---|
| < 10 GB | 1 个分片（多分片反而慢） |
| 10–100 GB | 2–5 个 |
| > 1 TB | 按时间分索引（ILM）+ 每索引少量分片 |
"小索引给很多分片"是最常见的错误：每个分片都是独立的 Lucene 索引，元数据与查询协调开销随分片数线性增长。
判据："单分片会不会超过 50 GB？" 会 → 加分片；不会 → 别再分。
4. 脑裂与选举（E-S13-008）
| 版本 | 机制 |
|---|---|
| 7.0 之前 | discovery.zen.minimum_master_nodes = N/2 + 1（手动配，配错就脑裂） |
| 7.0+ | 自动 quorum（基于投票配置），该参数已移除 |
脑裂后果：两个 master 各自接受写 → 数据分叉。
现代做法：奇数个 master-eligible 节点（3 个起），让自动 quorum 生效。
判据："master-eligible 节点是奇数吗？" 不是 → 调整拓扑。
5. 黄/红怎么读
| 状态 | 含义 | 常见原因 |
|---|---|---|
| green | 主副都分配 | — |
| yellow | 主分片 OK，副本未分配 | 单节点/副本数 > 节点数 |
| red | 主分片未分配 | 磁盘满、节点掉线、分片损坏 |
"单节点必然 yellow"（若副本数 ≥1）—— 这不是故障，是拓扑限制（实测本实例把副本设为 0 才 green）。
6. 五个误区
| 误区 | 真相 |
|---|---|
| "分片越多越快" | 元数据与协调开销上升 |
| "副本能提升写入" | 副本是写放大 |
| "yellow 一定是故障" | 单节点 + 副本 > 0 必然 yellow |
| "主分片数能改" | 只能 reindex |
"minimum_master_nodes 还要配" |
7.0+ 已移除 |
7. 自检
- 主分片与副本的差别？为什么主分片数不可改？
- 分片数的经验公式？
- 为什么"小索引多分片"是错误？
- 7.0 前后防脑裂机制的差异？
- yellow 与 red 的典型原因？
8. 下一篇
S13-J03 · 检索性能优化
集群讲完，下一篇讲"一条查询慢在哪"：profile API 的分解读法。
本篇属于系列《S13 · 搜索与文档存储》。旧文来源：A-1574；扩展点 E-S13-007/008。健康与分片信息为 ES 8.15.3 实测。