做数据库运维的同学，我相信绝大部分人都会遇到一个问题，那就是业务部门，或者开发人员，或者你的领导会问你，某某业务要上线了，评估一下数据库服务器的内存，硬盘容量是否满足业务需求，性能会不会有问题。
如果你不熟悉业务指标如何转换成MySQL数据库服务器选型指标，那么这时候，你肯定会一脸懵。我怎么会知道是否满足，要么拍拍脑袋，要么上128G内存，1TB SSD盘的服务器，反正越高配，肯定不会有错。
总之凭感觉，但是这种决策，很大概率会造成资源浪费，或者资源不足，不满足业务性能指标。
下面我就来详细说说，如何科学地进行数据库服务器选型。
业务指标- 业务请求在毫秒内返回
- 业务数据1年会产生1TB的数据
- 业务每秒请求量是10000
- 业务请求读写比是4：1
- 业务只访问15天以内的数据
解读：业务请求在毫秒内返回，当业务数据在内存里的时候，业务请求速度基本可以满足在毫秒内返回，所以需要将最近15天的热数据全部放入数据库的bufferpool里，所以15天热数据的大小，即为数据库的bufferpool大小。
业务只访问15天以内的数据业务数据1年会产生1TB的数据，那么15天的数据大小可以通过下面算式进行计算
(1*1024GB/365)*15=42GB，那么bufferpool的大小为42GB，再加上额外链接占用的内存2G左右，数据库占用内存为44GB
业务每秒请求量是1W，读写比为4：1，那么读请求为：100000.8=8000，写请求为：100000.2=2000
做最坏的打算，每次请求都是随机的，MySQL数据库默认页大小为16KB。
磁盘每秒写：2000/s16KB=32MB/s
磁盘每秒读：8000/s16KB=128MB/s
磁盘总的带宽为：32 128=160MB/s，再预留30%左右带宽，磁盘的总带宽为：160/(1-0.3)=228MB/s
通过上面的计算，服务器内存在50GB，磁盘带宽在228MB/s即可满足业务性能需求。
