决策：分片还是复制（扩展）？
数据库扩展决策取决于瓶颈在读还是写，以及数据能否容纳在单个节点上。错误的策略意味着不必要的复杂性或瓶颈得不到解决。这棵决策树首先提醒你最便宜、最简单的选项（垂直扩展、缓存），然后帮助你在只读副本和分片之间做出正确选择。
你是否先尝试了最简单的路径：垂直扩展和查询调优？
在转向分布式架构之前，先拿下最便宜的收益：升级硬件（CPU/RAM/IOPS）、添加缺失的索引并修复高开销查询，可以解决大多数瓶颈。只有在这些手段用尽时才增加复杂性。
- 没有 / 我还没有达到上限
- 是的，垂直扩展和调优已经不够
瓶颈在读，还是在写/数据量？
找出扩展问题的根源：是大量读查询压垮了单个节点（读密集），还是写入速率或总数据量超出了单个节点的容量（写/数据量密集）？这一区别正是副本与分片的根本差异。
- 读流量占主导，写入可由单节点承载
- 写入速率或数据量超出单个节点
读取是重复/可缓存的，还是新鲜且多样的？
进一步拆分读瓶颈：是一遍又一遍地读取相同的结果（缓存非常有效），还是读取请求多样、广泛且最新的数据（需要额外的读能力）？这决定了选择缓存层还是只读副本。
- 相同数据被反复读取，可接受轻微过时
- 多样/最新的读取，需要原始读能力
建议：先进行垂直扩展 + 查询调优
在转向分布式架构之前的首选且最便宜的路径。升级硬件并修复查询/索引，可以在不增加运维复杂性的情况下解决大多数扩展问题。
建议：只读副本（读扩展）
写入保留在单个节点（主库）上，读流量分发到一个或多个副本。这是为读密集型负载提升原始读能力和弹性的标准方法。
建议：缓存层
将频繁重复读取的结果保存在快速的内存层中，可大幅降低数据库负载。采用正确的模式，无需访问数据库即可响应，同时降低延迟和负载。
建议：分片（写/数据扩展）
数据按分片键（shard key）拆分并分布到多个独立节点；每个节点拥有一部分数据及其写入。这是扩展写入速率和总数据量的方法，但会显著增加复杂性。