TiDB 集群的硬件要求在官方文档中进行了总结。本节将介绍更实用的硬件选择和优化。请注意，如果工作负载不同，下文的细节可能有所不同，需要根据实际情况调整。
如果是典型的 TP 类场景，业务并发较高，但几乎都是点查点写，那么整个系统的瓶颈大概率先出现在 tidb-server，所以 tidb-server 的 cpu 高一点，数量多一点是一个更好的选择。 如果你有更多 OLAP 类的查询，内存通常会成为瓶颈。在以下情况中，可以考虑分配超过官方文档建议的 16GB 的内存：
主要负责全局唯一的事务号的分配，以及整个集群的元数据信息。所以 PD 不需要太多的资源，在集群规模较大,元数据较多的情况下，推荐使用 SSD 磁盘。但是 PD 的稳定性对于整个集群来说至关重要，生产环境推荐单独的服务器部署 PD，而且要有至少三个节点。对于非关键性工作负载或者非生产环境，你可以考虑将 PD 和 TiDB 组件部署在同一台服务器上，或减少 PD 实例数以降低成本。
TiKV 节点除了负责数据存储之外，也会负责部分的计算功能，通常情况下，TiKV 组件是最消耗资源的部分。为避免出现任何问题，建议你为 TiKV 多分配或预留些资源，特别是如果你预计不久后流量会大幅增加，则更应注意这一点。同时 TiKV 实例的个数必须不小于副本数(max-replicas)，考虑到 location-label ，TiKV 实例个数推荐是副本数的倍数，并且应当与你的数据量/业务相关。
在监控组件的硬件资源上，官方的建议比较大方，但实际情况你可以考虑缩小规模以节省一些硬件成本，4-8GB 内存、2-4 核 CPU 在大多数情况下已经够用了。建议不要把监控组件部署在一个 16GB 内存、8 核 CPU 的实例上，而是可以考虑部署在两个分别有 8GB 内存、4 核 CPU 的实例上，这样能保证 Prometheus/Alertmanager/Grafana 监控系统的高可用性。TiDB 后续也会推出支持监控高可用的部署方式。
建议使用：
Pump 非常占用磁盘和网络资源。你需要确保具有足够的磁盘空间和网络带宽，特别是如果业务不能承受较大的同步延迟，则更应注意这一点。
建议使用：
Drainer 主要占用很多网络资源。如果你的 Drainer 输出类型是文件，请确保具有足够的磁盘带宽，以进行准实时增量备份。
如果你计划使用 mydumper/myloader 进行备份与恢复，请确保使用具有足够磁盘和网络带宽的专用节点。建议使用：
如果你需要压缩转储文件，则应将内存增加一倍（即 64GB）。