数据库业务扩容时，内存先按热数据工作集配置到位，硬盘再按年增量加IOPS冗余排第二；两者不是容量比赛，而是命中率和延迟的配合。
见过太多故障工单，磁盘还剩一半，业务却卡得动不了；也见过一口气把硬盘扩到好几TB，高峰依然慢到超时，不是硬件买错了，是排布顺序反了，内存是前台抽屉，决定每次查询快不快；硬盘是后排仓库，决定数据放不放得下、扛不扛得住突发写入，扩库之前，先把这两个角色分清楚,后面配置单才不会跑偏。
数据库扩容先看瓶颈：慢和满根本不是一回事
数据库扩容的触发条件通常只有两个：变慢和快满,但很多团队把这两件事混在一起处理。
- 慢：查询延迟升高、接口超时、连接数堆积，这个锅多数由内存不足、SQL没走索引、锁等待造成。
- 满：磁盘使用率告警、归档日志堆积、备份空间不够,这个锅才轮到硬盘容量和清理策略。
如果业务是慢，扩硬盘基本没用；如果业务是满，加内存也解决不了根儿上的问题，所以动手之前，先打开监控看一眼，到底是磁盘队列在排队，还是缓冲池在频繁淘汰，定位错了,后面所有扩容动作都是花钱打水漂。
数据库扩容内存和硬盘怎么选？先算工作集，别先看总容量
数据库扩容最怕的，就是拿总数据量当内存采购依据，一个总容量500GB的库，真正高频访问的可能只有30GB，这30GB就是热数据工作集，它决定了内存的底线，硬盘呢，要同时满足容量、IOPS、延迟三个条件,单看剩余GB数最容易踩坑。
数据库服务器内存多大合适？用监控数据倒推，别拍脑袋
内存该配多少，不要靠经验猜,数据库的监控数据会直接告诉你答案。
先看操作系统层，登录服务器执行 free -h，swap 这一行长期不是0，说明物理内存已经被打穿，系统在拿磁盘当内存用,这时候业务不慢才怪。
再进数据库层，MySQL 可以查询 SHOW ENGINE INNODB STATUS，重点盯 Buffer pool hit rate，PostgreSQL 可以查看 pg_stat_statements 和 pg_buffercache，如果命中率长期低于九成半，基本可以判定内存不够,热数据不能被稳定缓存。
还有一条更直观的路：看慢查询，把慢日志导出来，数一数有多少SQL的耗时集中在磁盘读上，如果磁盘读耗时占比明显高于CPU，多半是内存没兜住热数据,每次查询都要跑到硬盘上现读。
参考配置量级可以这样理解：
- 轻量CMS、后台管理,16GB起步通常能稳住。
- 中型电商、CRM、ERP，主库建议64GB往上,从库可适当减半。
- 大型交易、实时风控、高频写入,128GB到512GB并不夸张。
但内存也不是越大越好，如果SQL本身是全表扫描，加内存只是把慢查询暂时藏起来，数据量一涨还是现原形，内存扩容要和SQL优化并行做,才能把每一GB花在刀刃上。
硬盘不能只看剩余容量，IOPS和延迟才是主库命门
很多云盘标称容量很大，价格也不贵，但一跑数据库就原形毕露，问题不在GB，在 IOPS 和 延迟，主库每秒可能有上千次随机读写,机械盘几百的IOPS根本扛不住。
| 硬盘类型 | 随机读IOPS量级 | 适合数据库场景 |
|---|---|---|
| SAS HDD | 百级 | 冷备、归档、日志存储 |
| SATA SSD | 万级 | 小型库、从库、开发环境 |
| NVMe SSD | 十万级 | 主库、高频OLTP、实时写入 |
| 云ESSD/极速型云盘 | 十万级起，按容量线性提升 | 云上主库、弹性扩容 |
选硬盘时，先把业务的峰值QPS和平均查询大小测算出来，再反推需要多少随机读写能力，只看容量买最低规格的云盘，主库一上线就会因为IOPS耗尽而出现诡异超时。数据盘和日志盘要分开，redo、binlog、pg_wal这类顺序写入不能和数据文件的随机读写抢同一个磁盘。
云数据库扩容价格跟着内存和存储双涨，先算清再下单
云数据库扩容价格通常由内存规格和存储规格两部分组成，内存越往上加，单价涨幅越明显，所以先算清楚工作集，再决定内存档位,能避免为用不上的容量长期付费。
存储侧也一样，同一容量的云盘，IOPS等级不同，价格可能差出一截，主库选高IOPS云盘，从库可选通用型SSD，归档库甚至可以落到对象存储或低频盘，不同云厂商的规格名称不同，但逻辑一致：
用性能等级匹配业务分层,别全库一视同仁花冤枉钱。
数据库扩容硬盘要多大？留出一年增量再加安全水位
硬盘容量规划，最忌讳只按当前数据量精确计算，数据库不是静止的，日志会涨，备份会涨,临时表空间也会在跑大事务时突然膨胀。
一个实用估算法：
- 当前数据量是多少
- 平均每天增量是多少
- 保留周期内的日志、备份、快照占多少
- 大表DDL、归档任务、临时文件需要多少弹性空间
假设当前数据800GB，每天增量2GB左右，一年增量就是700GB上下，再加上redo、binlog、备份快照各几百GB，最后留三到五成安全水位，这样算下来，一般就会选到2TB以上，硬盘水位不要等到90%才动手，很多数据库在75%左右就开始出现性能抖动，提前扩,永远比半夜告警再紧急处理从容。
云盘的好处是在线扩容，不用停机，文件系统用XFS或ext4配合 resize2fs 或 xfs_growfs 可以平滑扩展，但要注意，容量扩了，IOPS等级可能没有跟着涨，尤其部分云盘规格的IOPS和容量强绑定,扩容前一定先确认性能上限是否同步提升。
北京数据库扩容方案：地域选择比硬件参数更影响体验
如果业务部署在北京，数据库也尽量放在北京同地域的机房或可用区，跨地域主从延迟、公网访问抖动、备份恢复慢，这些问题很多时候不是规格不够,而是网络路径太长。
- 云上用户优先选北京地域多可用区部署，主备之间走内网同步,延迟可控。
- 自建机房选北京本地托管机柜,确认好BGP多线带宽和机柜电力冗余。
- 跨地域容灾可以单独规划,但日常读写链路不要绕远。
地域选对了，同样的规格，用户体验会好很多，北京本地访问北京机房的数据库，和内网调用几乎是一个量级；跨地域访问，就算带宽再大，物理距离摆在那里,延迟骗不了人。
实操顺序：先基准测试再扩，别凭感觉下单
排布要有章法，按下面顺序来，操作路径清晰,也能给后续维护留下依据。
- 采集一周高峰监控：CPU、内存使用率、缓存命中率、磁盘IOPS、慢查询日志。
- 计算热数据工作集,确定内存下限。
- 估算一年数据增量，加上日志、备份、临时空间,确定硬盘容量和类型。
- 云上选规格时，先升内存到目标档位，再扩磁盘,分批验证。
- 改完参数后做一次基准压测,对比扩容前后的延迟和吞吐。
- 最后灰度切流,别一次性把全量业务压在刚扩容的实例上。
常见错误配置：内存给了，硬盘还是慢
排布对了能让业务平稳降落，排布错了，钱花了照样出问题,以下都是高频踩坑点：
- 主库用了机械盘或低IOPS云盘，内存扩得再大,写入日志时照样卡住。
- 只扩数据盘，没管redo、binlog、pg_wal日志盘,写入排队拖垮全库。
- 内存加到256GB，但
innodb_buffer_pool_size还是默认小值,等于白扩。 - 热数据估算错误，全表扫描SQL把缓冲池冲得七零八落,命中率上不去。
- 只看硬盘总容量，不看云盘规格的IOPS上限,容量剩一半性能先触顶。
数据库扩容不是简单的买买买。内存先兜住热数据，硬盘再兜住年增量和峰值IOPS，顺序反了，配置再高也压不住高峰期的延迟，把工作集算明白，把磁盘性能选对,扩容才真正解决问题。
数据库扩容内存和硬盘哪个优先？
先看监控，缓存命中率长期低、swap使用频繁、慢查询以磁盘读为主，优先扩内存；磁盘水位持续超过八成、写入延迟升高、归档日志堆积，优先扩硬盘，多数在线交易库的日常卡顿,内存优先能解决更明显的问题。
数据库扩容硬盘要多大合适？
按当前数据量加一年自然增量，再加日志空间、备份快照、临时表空间，最后留三到五成安全水位，云盘还要确认IOPS等级是否和容量同步提升,避免只扩大小不扩性能。
北京数据库扩容方案怎么选？
优先选择与业务同地域、同VPC的云数据库多可用区部署，支持在线扩容、读写分离和自动备份，自建则选北京本地机房并确认BGP多线带宽,同地域部署可以把业务访问数据库的网络干扰降到最低。