RDS规格怎么选择合适？连接数、内存与I/O一起核对
选择RDS先看实际数据库负载，再查具体引擎、架构、系列和规格代码。相同2核4G也不代表相同连接上限或I/O能力；日PV不能直接换算数据库连接数。本文纠正旧页混用规格代码、连接数与报价的问题，保留慢查询优化、连接池和读写分离的判断方法，不提供一张按网站规模保证容量的配置表。
先区分四类限制
| 资源 | 需要记录 | 常见误读 |
|---|---|---|
| CPU与内存 | 高峰计算、热数据集、排序及缓存 | 内存越满就一定该升级 |
| 连接数 | 总连接、活跃连接、等待与连接池 | 最大连接数等于最大并发查询 |
| 磁盘 | 空间增长、IOPS、吞吐、时延 | 只看CPU就能选型 |
| 架构与系列 | 基础、高可用、集群及部署范围 | 任何规格都有自动主备切换 |
官方倚天版表中，基础系列mysql.n2e.medium.1为2核4GB、最大连接数2000；高可用通用型mysql.n2m.medium.2c同为2核4GB，表列最大连接数4000。这只是指定系列与代码的示例，不可外推到全部RDS，更不是可保证完成同等数量的查询。
容量估算要从SQL而非PV开始
记录峰值事务或SQL请求速率、平均服务时间、SQL复杂度、索引和缓存。平均在途请求数可近似为每秒请求数乘平均耗时，时间单位必须为秒；这是负载估计，不是连接池大小的直接推荐。页面请求还可能触发多条SQL，空闲连接和后台任务也占用连接。
假设每秒100个数据库请求、平均耗时0.1秒，则平均在途请求约10个。这个示例不包含突发、锁等待、连接池空闲占用和长事务，应当用实际高峰及分位响应时间验证，而不是凭日均访问量加一个固定峰值系数就下结论。
存储与实例共同决定I/O
官方规格说明明确，实际最大IOPS和IO带宽受存储类型、存储空间与实例规格共同影响；通用型规格不能保证表列最大IOPS及最大IO带宽。需要稳定I/O时，把独享型及合适存储列为候选，并测试业务工作集。
慢查询、缺失索引、大事务和全表扫描也会放大I/O需求。先查慢日志和执行计划，再比较升级CPU、增加内存、调整存储或优化SQL的成本。不要保证换盘统一提升5到10倍，也不能把只读实例当作写入瓶颈的解决方案。
连接池与只读实例何时有意义
- 连接数高但活跃查询不多：先查连接泄漏、空闲连接和应用实例数量，合并计算各连接池最大值。
- 读查询拖慢主库：评估索引、缓存及只读实例分流，确认应用路由和复制延迟容忍度。
- 写入或锁竞争严重：排查事务与热点，不盲目添加只读节点。
- 报表影响在线业务：测试隔离分析负载，并将新节点费用纳入预算。
连接池上限、超时和数据库参数均需结合应用测试。不能直接把示例maxActive或wait_timeout复制到所有项目；也不要宣称只读实例固定是主库半价。
变配和采购的最后检查
按相同地域、引擎版本、架构、存储和期限比较报价，把备份超额、只读节点、代理、网络及后续增长单独列出。测试环境同样需要必要备份和权限管理，不因“非生产”就默认数据可丢。
变更配置须核对当前实例的升降配支持、生效方式和可能的连接闪断。两份旧文分别承诺“包年不能降配”与“随时在线无影响”，都不应一概保留。安排低峰、自动重连、回滚及备份，不保证固定30秒恢复。以覆盖实际业务高峰的监控和测试结果决定配置，不按统一70%阈值立即采购。
常见问题
日活5000就需要4核8G吗？
没有这种固定关系。读写比例、每次SQL成本、缓存与锁竞争不同，必须用实际业务数据测试。
小规格测试后转包年一定划算吗？
不一定。要比较预计运行时长、可售规格、优惠、续费与迁移费用，不能用固定折扣或每小时示例价替代实际订单。
下一步如何决定
把引擎、系列、规格代码、连接预算和存储上限写在同一份配置记录中。若瓶颈尚未定位，先优化和测试；只有性能目标与完整预算都明确，才提交新购或变配订单。
官方参考资料
查阅日期：2026-10-16。资料用于说明所列规则，不构成对未来价格、库存或优惠资格的承诺。