分索引优于盲目增加Shard数量：I/O压力与可控性的取舍

当单个索引变得越来越大、查询速度随之下降时，一个直觉上的解法是给这个索引增加更多Shard（分片）来分摊压力，但实践经验表明这条路走不通：更多的Shard会带来额外的I/O压力，官方文档也建议一个Node最好不要多于3个Shard，如果真的要”更多Shard”，唯一的办法是配更多机器，但这在很多场景下并不现实（书中提到256个Shard的集群就变得极难控制，每次扩容都很慢）。更有效的替代方案是”分索引”——不是在同一个索引内堆Shard，而是把数据按业务维度（比如每个大分类一个索引，或每个主要大城市一个索引）拆分成多个独立的、Shard数量可控（3个以内）的索引，查询时再通过Elasticsearch原生支持的合并查询语法（在URL里同时指定多个索引名和对应的routing参数），把原本该由一个巨型索引承担的查询，动态路由并聚合到多个小索引上完成。这个思路和[[Routing是查询性能优化的”王道”：把查询流量按维度拆分到独立小集群]]是同一套治理哲学在索引结构层面的体现：面对规模增长带来的压力，优先考虑”按业务维度拆分成多个可控的小单元、查询时再按需合并”，而不是简单粗暴地在同一个单元内部堆资源——后者的边际收益会随着规模增长而递减（更多Shard带来的I/O开销会抵消并行处理的收益），前者则能让每个独立单元始终保持在一个可控、可预测的规模区间内。