别再瞎买服务器了！老板问数据库要多少核，你就把这篇文章甩给他
昨晚两点，手机震得跟按摩棒似的，我还以为客户机房着火了，一看钉钉，开发在那嚷嚷：“哥，数据库又崩了，是不是咱们机器配置不行啊？要不申请换个万兆网卡的机器？”
我当时那火气蹭地一下就上来了。还没排查问题呢，上来就赖硬件，这锅背得我腰疼。爬起来一看监控，好家伙，QPS 还没到平时的一半，倒是那慢查询日志刷得跟瀑布一样。这就好比你开个法拉利去早高峰的二环，你跑不快能怪车不行吗？
这事儿让我想起来，其实很多做技术的，甚至干了好几年的兄弟，对数据库的性能指标、容量测算这块儿，心里其实是一笔糊涂账。每次新项目上线，问DBA要机器，要么是“拍脑袋”——给个最大的；要么是“看面相”——以前用多少现在就用多少。
今天咱们就不整那些虚头巴脑的概念了，咱们聊点实实在在的。也就是当你面对一个新业务，或者要给老板汇报为什么要买这台几十万的服务器，或者为什么AWS账单上那个RDS费用那么高时，你得拿得出手的那些“硬通货”。
QPS高就是性能好？那你可能被骗了
我们先得把“性能”这个词拆开来看看。很多人觉得数据库快就是好，慢就是差。但“快”是多维度的。
咱们先说 QPS 和 TPS。这俩货是大家最爱挂嘴边的。QPS（Queries Per Second）就是每秒查询数，TPS（Transactions Per Second）是每秒事务数。听着挺简单对吧？但这里面坑深着呢。
有个误区，很多人觉得QPS高，数据库压力就大。其实不一定。你执行一万次 SELECT * FROM user WHERE id = 1（走主键索引），和你执行一次 SELECT * FROM user WHERE name LIKE '%王%'（全表扫描），这能一样吗？前者QPS可能飙到几万，CPU纹丝不动；后者QPS可能才几十，CPU直接打满，甚至IO都给你堵死。
所以，我看监控的时候，从来不单看QPS的绝对值，我更看重的是 QPS和CPU Usage的比率。如果QPS很高但CPU很低，说明大家都在乖乖走缓存、走索引，这时候系统极其健康；反过来，QPS没多少，CPU却在那狂啸，兄弟，赶紧去查慢SQL吧，绝对有那种没建索引的查询在作妖。
IOPS和延迟：这才是老板不懂的“命门”
再来说说 IOPS。这个指标，很多开发不太关注，但对于我们搞运维的来说，这简直就是命门。简单说，就是硬盘每秒能进行多少次读写操作。
现在的业务，尤其是在线交易类的，大部分都是随机读写。机械硬盘（HDD）在这个环节基本上就是个废物，一块高性能的SAS盘，IOPS也就几百撑死了。而现在的SSD，尤其是NVMe的，随便都能干到几十万。
为什么要提这个？因为经常有这种事：业务方说“我要存10T的数据”，于是你给配了个超大容量的SATA盘。结果上线没几天，卡得动不了。一看容量才用了100G，但IOPS直接瓶颈了。
数据库这玩意儿，本质上就是在玩I/O。内存不够了，要去磁盘读，这就叫物理读；内存够，直接在Buffer Pool里命中，叫逻辑读。所有的性能优化，归根结底就是想办法把物理读变成逻辑读，或者让物理读更快一点。
说到这，就不得不提一个让无数人翻车的指标：Latency（延迟）。
通常大家看延迟，喜欢看平均值（Average）。“哦，平均响应时间10ms，挺好。” 好个屁。平均值是最会骗人的。马云身价万亿，我和他一平均，我也是亿万富翁，但这能说明我有钱吗？
在数据库领域，一定要看 P99 或者 P999。这代表了99%的请求都在这个时间内完成。因为往往就是那1%的慢请求，拖垮了整个连接池，导致系统雪崩。我看过太多次，平均延迟才5ms，但P99已经飙到了2秒，前台用户那就是在那转圈圈，体验极差。
老板问要多少核？拒绝“拍脑袋”，咱们得算
好了，指标大概心里有数了，咱们聊聊那个最头疼的问题：怎么测算？
场景来了：产品经理跑过来说，“咱们下个月搞大促，预计有100万用户参与，你给估算一下数据库要多大配置。”
这时候你要是直接回答“搞个64核128G的吧”，那你就是纯纯的韭菜。
咱们得算。怎么算？得有一套逻辑。
首先，把业务语言翻译成技术语言。100万用户参与，是指注册？还是指同时在线？还是指每天的总访问量（DAU）？这个差别大了去了。
假设是DAU 100万。按照互联网的尿性，用户不会24小时平均分布。这就用到了 二八原则。80%的访问量，通常会集中在20%的时间段里。
来，拿出计算器，咱们按按：
- 计算平均QPS： 假设每个用户上来平均操作10次数据库（这就需要你跟开发去确认业务逻辑了，比如登录查一次，刷列表查三次，点赞写一次等等）。
总请求数 = 100万 DAU * 10 = 1000万请求/天。
如果按天平均算，一天86400秒，1000万 / 86400 ≈ 115 QPS。看着不多是吧？ - 计算峰值QPS： 套用二八原则。
(1000万 80%) / (86400 20%) = 800万 / 17280 ≈ 462 QPS。
这只是常规峰值。如果是有秒杀活动，那可能几秒钟内涌入几十万请求。那种情况不能按二八原则算，得按 倍数法，通常是常态峰值的5-10倍，甚至是百倍。
硬件选型：CPU和内存的“黄金比例”
算出了QPS/TPS，接下来就是 选硬件。
这里有个经验值（仅供参考，具体得看你的业务类型是读多还是写多）：
- CPU：一般来说，MySQL在优化良好的情况下，一个Core大概能支撑1000-1500左右的简单QPS。如果你的业务逻辑复杂，有不少Join，那这个数字得打三折。
- 内存：这个是重中之重！内存越大，能缓存的数据越多，物理I/O就越少。我的建议是，热数据最好能全装进内存里。 比如你数据库总量1T，但最近7天会被频繁访问的数据只有50G，那你内存起码得配个64G或者96G，留给操作系统和Buffer Pool。
上云就万事大吉？AWS RDS里的那些“氪金”陷阱
说到磁盘和存储，这里得重点唠唠 云数据库（RDS），特别是 AWS RDS。
现在很多公司都上云了，觉得上云就万事大吉。但我见过太多在AWS上栽跟头的。
普通的云盘，比如AWS的通用型SSD（gp2/gp3），它的性能其实是有“基准线”的。以前用gp2的时候，容量越小，IOPS越低，你要想获得高IOPS，就得被迫买很大的容量，这叫“捆绑销售”。
现在gp3出来了，稍微好点，可以独立调整IOPS了，但它还是有上限。
这时候，AWS的一个大杀器——Provisioned IOPS（预配置IOPS，也就是io1/io2）就得登场了。
这玩意儿是什么概念？简单说，就是 “氪金变强”。
在自建机房，你的IOPS受限于物理硬盘的性能，插满SSD也就那样了。但在AWS上，只要你肯花钱，你可以指定你的RDS实例拥有多少IOPS。
比如说，你的业务是高频交易，数据量不大，才500G，但是并发写特别猛，每秒几万次的写入。用普通的SSD，早给你卡死了。但是用AWS RDS的 io1 或 io2，你可以直接大手一挥：“给我来 40,000 IOPS！”
AWS底层会通过多重技术手段给你保证这个性能。尤其是现在的 io2 Block Express，号称能提供亚毫秒级的延迟，IOPS能干到几十万，基本上等同于把你数据库塞进了顶级SAN存储里。
但是！这里有个巨坑，兄弟们记住了。
虽然AWS RDS可以指定IOPS，但它是 单独收费 的，而且贵得离谱！
我以前有个项目，为了追求极致性能，手滑把IOPS设置得太高，结果月底账单出来，数据库的存储费用比计算实例（EC2/RDS Instance）的费用还高出两倍！老板看着账单，脸都绿了，问我是不是在数据库里挖矿。
所以，测算在这里就显得尤为重要。你必须知道你的业务真实需要的IOPS是多少。
怎么看？去CloudWatch看 WriteIOPS 和 ReadIOPS 的监控数据。
如果你的峰值才3000，千万别为了“安全感”去买10000的Provisioned IOPS。
对于大多数中小业务，AWS新的 gp3 卷其实性价比最高，它免费送你3000 IOPS，超过的部分可以单独买，价格比 io1/io2 亲民得多。
总结一下关于AWS RDS的选型策略：
- 穷人/测试/小业务：用 gp3，默认3000 IOPS 够大多数场景喝一壶了。
- 核心业务/大促/高频交易：必须上 Provisioned IOPS (io1/io2)。这时候别省钱，因为一旦IOPS被打满，数据库的Latency会直接起飞，整个APP就瘫痪了。哪怕只开大促这几天，也得把它加上去。
- 监控：一定要设置
DiskQueueDepth（磁盘队列深度）的报警。如果队列深度持续很高，说明IOPS不够用了，这时候要么加钱升级IOPS，要么去优化你的烂SQL。
压测是在耍流氓？不带数据的测试都是扯淡
光算出来不行，还得 压测。
很多兄弟压测就是走个过场，拿个sysbench默认参数跑一下，“哦，TPS 5000，够用了”，然后上线就挂。
压测必须要模拟真实业务场景！
你得知道你的业务是读写比是多少。是9:1？还是1:1？
数据分布是什么样的？是均匀分布，还是热点分布？
sysbench是可以定制lua脚本的，别懒，去写几个脚本，模拟真实的SQL语句。
举个真实例子。我以前接手过一个电商库，上线前压测QPS那是杠杠的，两万多。结果上线当天，只要一下单就卡死。
后来排查发现，压测的时候，数据量小，全是内存操作。上线后，商品描述字段特别大（存了HTML代码），一查询就产生大量的临时表，内存放不下，全部落盘到磁盘上进行排序。磁盘IO瞬间打满。
这告诉我一个道理：不带数据量的压测，都是耍流氓。 你得先往库里灌入几千万条基础数据，再去跑压测，这时候测出来的性能才是接近真实的。
连接数与内存：别让系统死在这些细节上
还有个大家容易忽略的点：连接数（Connections）。
经常看到有文章写“MySQL最大连接数设置得越大越好”。这简直是误人子弟。
MySQL是每一个连接对应一个线程（虽然后面有了线程池，但大部分场景还是传统模式）。线程多了，上下文切换（Context Switch）的开销就大了。
这就好比一个窗口办事员，同时接待1000个客户，每个人问一句，他得切换1000次大脑回路，最后谁的事也办不成。
通常来说，连接数设置在2000-3000就顶天了。如果业务报错“Too many connections”，你要做的不是无脑调大参数，而是去检查代码里是不是没关连接，或者引入Proxy层（比如ProxySQL、MyCat）去做连接池复用。
再聊聊 Buffer Pool 的命中率。
这是衡量内存够不够用的金标准。怎么看？show global status like 'Innodb_buffer_pool_read%';
计算公式大概是：1 - (Innodb_buffer_pool_reads / Innodb_buffer_pool_read_requests)。
如果这个数字低于99%，说明你的内存太小了，或者你的SQL在做大量的全表扫描，把热数据从内存里挤出去了。这时候，要么加内存，要么砍死写烂SQL的程序员。
监控的艺术：寻找那个“甜点”
其实啊，测算和规划，很大程度上是一种“平衡的艺术”。
你想保证万无一失，可以给老板报一个超高的配置，比如128核/1T内存/5万IOPS。系统肯定稳，但老板看财报的时候脸会绿，你也体现不出技术价值。
你想帮公司省钱，搞个低配，整天提心吊胆，半夜爬起来处理故障，那是跟自己过不去。
最牛逼的运维，是能在业务增长曲线和硬件成本之间，找到那个 Sweet Spot（甜点）。
怎么找？
监控，监控，还是TMD监控。
不要只在出事的时候才看监控。平时的波峰波谷，你要心里有数。
比如，你要知道每周五晚上8点是流量高峰，那这周五你看CPU是30%，下周五变成了35%，虽然离报警线还早，但你得警觉：数据量在增长，或者有人上线了烂代码。
这种趋势的洞察，比单纯的报警更有价值。
最后，我想说的是，没有什么“万能公式”。
所有的测算，都只是一个起点。真实的生产环境千变万化。
可能今天是因为由于机房空调坏了导致CPU降频；
可能明天是因为RAID卡电池没电了导致写策略从Write Back变成了Write Through，性能跌成狗；
也可能仅仅是因为开发往表里加了个大字段，导致页分裂频繁。
更可能像我前面说的，AWS的Credit耗尽了，性能直接被掐断。
我们做运维的，就是要在这个不确定的世界里，寻找确定性。
怎么寻找？
就是靠咱们平时的积累。
多做压测，多看源码，多分析慢日志，多去了解业务，特别是要去了解云厂商那些藏在文档角落里的限制条款。
当你能脱口而出：“这个业务模块，并发大概500，主库CPU大概在20%，建议上AWS RDS io1，给个3000 IOPS保底，不然大促扛不住”的时候，你在公司里的地位，那就稳了。
总结一下：
- 别光看QPS，要结合CPU和IO一起看。
- 延迟要看P99，平均值是哄鬼的。
- 容量测算要懂二八原则，还要预留冗余。
- 玩AWS RDS要懂IOPS的门道，gp3性价比高，io1/io2是给土豪和关键业务准备的，别乱买，也别不舍得买。
- 压测要带数据量，模拟真实业务场景，别拿空库跑分。
- 监控要看趋势，不仅仅是看报警。
好了，今天就扯这么多。写得有点散，但都是我也算是掏心窝子的经验了。这些东西书上不一定有，培训班也不一定教，全是踩坑踩出来的血泪史。
如果你觉得今天这篇文章对你有那么一点点启发，或者帮你避开了一次“背锅”的风险，麻烦动动手指转发一下。
这年头，写点实战干货不容易，全靠兄弟们帮衬。
如果这篇文章对你有帮助，别忘了点赞转发支持一下！想了解更多运维实战经验和技术干货，记得关注微信公众号@运维躬行录，领取学习大礼包！！！我会持续分享更多接地气的运维知识和踩坑经验。让我们一起在运维这条路上互相学习，共同进步！
公众号：运维躬行录
个人博客：躬行笔记
