# 典型数据库容量评估要点 - MySQL

+ 集群个数
  + 如果写入 QPS 较大（10,000 以上），建议进行实例拆分
  + 考虑未来业务增长情况
+ 内存大小
  + 确保 InnoDB Buffer Pool 命中率大于 99%
+ 单表大小
  + B+ Tree 层数控制在 3 层以内

----------------------------------------------------
MySQL 是当前最流行的传统开源关系型单机数据库，在容量评估方面相关的基准测试评估数据较大，运维人员的场景经验也比较丰富。容量评估中除了以上介绍的实例个数和存储大小的评估外，需要重点关注的是有以下几点：

1. 集群个数评估
受限于 MySQL 基于逻辑并行复制的能力，如果写入 QPS 较大，例如 10000 或者20000 +QPS，则需要根据以上容量评估的方法评估出当前集群可支撑的最大写入 QPS 后，进行集群的拆分，建议拆分时考虑到未来 2-5 年的业务增长情况。

2. 实例内存大小评估
实例内存主要影响的是Buffer Pool 的命中率，其对 MySQL 的读写性能影响较大，建议命中率保持在 99+% 来获得性能和资源间的相对平衡，所以需要确保业务的热数据可以缓存在 Buffer Pool 中。例如总数据量 1000GB，热数据比例为 20% 200GB，Buffer Pool 配置比例为总内存的 75%，则至少需要实例内存大小为：267GB。

3. 单表大小评估
MySQL 基于 B + Tree 结构存储行记录和索引，根据 B+Tree 的特征，检索记录的IO次数和 B+ Tree 的层级相关，如果 B+ Tree 层级为 3 则每次聚簇查询都需要检索 3 个数据页。如果随着数据量的增加，B+Tree 的层级增加到了 4 层，则每次聚簇索引检索就会从 3 次变为 4 次，对性能会有较大的影响。所以使用 MySQL 一般会限制单表数据量在千万级别（ 2000 千万左右，跟主键大小相关，一般为 3 层 B+tree）。