为数据库服务器选型前，先把事务读写比梳理清楚，能直接决定CPU核数、内存容量、存储介质和网络带宽的配置下限，避免为用不上的性能花钱。
为什么事务读写比是选型的第一道滤网
数据库服务器选型最容易犯的错,是拿业务总流量当配置依据，比如日活几百万、表里有上亿行数据，听起来很吓人，结果买回来一台四路服务器，CPU平时利用率不到两成，问题就出在没有把事务拆成读和写。
事务读写比,指一个业务周期内数据库执行的读操作与写操作的比例，读操作主要是SELECT，写操作包括INSERT、UPDATE、DELETE，这个比例直接决定硬件资源往哪里堆。
- 读多写少的库,瓶颈通常在内存命中率和只读副本扩展能力。
- 写多读少的库,瓶颈通常在磁盘顺序写入速度、WAL日志落盘延迟和锁竞争。
- 读写混合且峰值明显的库,瓶颈通常在连接数、CPU上下文切换和存储IOPS。
不梳理读写比,选型就变成猜谜，要么按最大流量配置，预算翻倍；要么按平均流量配置，大促时雪崩，先算比例，再看峰值，最后定硬件，顺序不能反。
数据库服务器选型怎么评估读写比才不踩坑
评估读写比不能凭感觉,开发说“我们这个库读多写少”，结果量产后写放大严重，redo日志把NVMe盘打满的例子很多，要用日志和统计表说话。
用慢日志和审计日志做基础统计
MySQL、PostgreSQL、Oracle都提供语句级别的统计入口，以下命令可以直接在现网从库或离线环境执行。
MySQL 8.0查看各类语句次数：
SELECT DIGEST_TEXT, COUNT_STAR, SUM_ROWS_SENT, SUM_ROWS_EXAMINED FROM performance_schema.events_statements_summary_by_digest WHERE DIGEST_TEXT LIKE 'SELECT%' OR DIGEST_TEXT LIKE 'INSERT%' ORDER BY COUNT_STAR DESC LIMIT 50;
PostgreSQL查看事务读写比例：
SELECT queryid, calls, rows, query FROM pg_stat_statements WHERE query ILIKE 'SELECT%' OR query ILIKE 'INSERT%' OR query ILIKE 'UPDATE%' ORDER BY calls DESC LIMIT 50;
用pt-query-digest分析慢日志时，关注输出里的读写比例汇总，Oracle则可以直接查V$SQLAREA里的FETCHES和EXECUTIONS。
把语句归成三类再计算
拿到原始日志后,按以下规则归类：
- 只读事务：只有SELECT，不含FOR UPDATE。
- 写事务：包含INSERT、UPDATE、DELETE，且每笔写操作通常伴随WAL落盘。
- 读写混合事务：先SELECT再UPDATE，常见于扣库存、转账场景。
然后用当天峰值时段的日志计算比例,不要用全天平均，高峰期的读写比才决定服务器上限，例如早高峰报表跑批时读占比突然拉高，晚高峰下单时写占比拉高，都要分开采样。
判断要不要用只读副本分担读压力
如果读占比明显偏高,且读请求可以容忍秒级延迟，选型时就应该把主从架构纳入考虑，主库专注写，从库承接读，这个决策反过来影响主库的CPU和内存配置主库不需要为大量读查询预留太多内存，省下的钱可以加到从库或缓存层。
从读写比推导CPU、内存、磁盘的配置权重
读写比落定后,硬件选型就有了明确的映射关系，下面这张表给出常见场景的配置偏向。
| 读写比特征 | CPU要求 | 内存重点 | 磁盘要求 | 网络要求 |
|---|---|---|---|---|
| 高读低写，如内容展示库 | 核数可适中，主频不敏感 | 大内存用于缓存热点页 | SATA SSD即可，NVMe收益低 | 内部带宽一般 |
| 高写低读，如日志库、埋点库 | 主频高，核数跟并发写匹配 | 内存适中，WAL缓冲区要够 | NVMe SSD，独立日志盘 | 落盘网络要稳 |
| 读写均衡，如订单核心库 | 核数与TPS线性匹配 | 内存要覆盖热数据和索引 | NVMe SSD，读盘写盘分离 | 高吞吐低延迟 |
读多写少场景的操作路径
- 先测内存命中率,用InnoDB Buffer Pool命中率或PostgreSQL shared_buffers命中率作为指标。
- 命中率低,优先加内存，而不是加盘。
- 内存加到数据量级后仍扛不住,再考虑只读副本。
- CPU核数按并发读连接数估算,一般每个连接对应一个查询线程。
写多读少场景的操作路径
- 把WAL日志放到独立NVMe盘,和业务数据盘分离。
- 核对
innodb_flush_log_at_trx_commit和fsync频率，确认峰值写不会打满单盘IOPS。 - 写并发高时,优先提高CPU主频和单核性能，因为事务提交路径上的锁和日志写是单线程敏感的。
- 内存不用盲目翻倍,写密集库的数据页很快被覆盖，缓存收益有限。
订单库和报表库的读写比对比，选型逻辑完全不同
同一个业务系统里,不同库的读写比可能天差地别，拿电商系统举例。
订单库在秒杀场景下,写事务瞬间膨胀，INSERT订单、UPDATE库存、写流水日志，几乎每一笔都是写，此时磁盘顺序写入能力和WAL落盘速度决定系统生死，选型如果还按普通OLTP库的“大内存读缓存”思路走，一定会卡在磁盘IO上。
报表库则相反,报表读的是历史订单、用户行为汇总，大多数请求是聚合查询、范围扫描，写操作主要发生在夜间ETL任务里，报表库需要大内存来缓存常用维度表、大带宽来支撑并行扫描，磁盘用SATA SSD甚至机械盘都能接受。
两张表放一起对比：
| 业务库 | 典型读写比 | 选型关键词 | 钱花在哪 |
|---|---|---|---|
| 订单核心库 | 写比例在高峰期明显偏高 | 高主频CPU、NVMe独立日志盘 | 磁盘和CPU主频 |
| 报表分析库 | 读占绝大多数 | 多核CPU、大内存、列式存储 | 内存和并行算力 |
数据库服务器选型怎么评估读写比”这件事，本质上要求先拆分业务模块，不要给整个系统一个笼统的读写比，而要按订单库、用户库、报表库分别统计，再分别选型。
数据库服务器价格差距主要差在哪：读写比决定钱花在哪里
两台看起来都是2U机架式服务器,配置单价格可能差出一倍多，差价集中在几个地方：
- NVMe SSD与SATA SSD：写密集库必须上企业级NVMe，读写混合型IOPS比SATA高出一个数量级，单盘价格也高出不少。
- 高频CPU与多核CPU：高写库需要高主频，比如睿频更高的型号；高读库更看重总核数，主频略低也能接受，两者价差可能达到整机的两三成。
- 内存通道与容量：大内存配置在报表库上提升明显，但写密集库配过大内存属于浪费。
- 网卡与交换层级：读写均衡的核心库需要双25G或更高网卡，边缘报表库用万兆甚至千兆都够。
把读写比梳理清楚后,价格判断就简单了，写比例高，把预算优先给磁盘和单核性能；读比例高，把预算优先给内存和核数，这个顺序反了，就会出现“花旗舰的钱买来中端体验”的情况。
成都地区数据库服务器配置方案里的读写比权重
地域因素也会影响读写比到选型的落地,以成都地区的私有云和托管机房为例，本地企业常见的做法是核心库托管在成都本地IDC，报表和分析库放在云上弹性扩容。
成都机房到云厂商可用区的网络延迟通常在个位数毫秒,适合做主从同步，这种情况下，读写比会直接决定同步架构：
- 读多写少且读集中在成都本地,可以在本地主库旁挂物理只读副本，应用就近访问。
- 写多读少且写来自全国,可以把主库放在成都机房，异地只做灾备，不在异地建大量只读节点。
- 读写均衡又要求同城双活,成都两个可用区之间同步需要低延迟链路，预算里要包含专线或同城互联费用。
成都的服务器租赁市场里,带企业级NVMe的机型比标准SATA SSD机型租金高出一档，写比例高的订单库，不建议为了省租金选SATA SSD，后期写入延迟会拖垮整个事务链路。
实操：用三张表把读写比换算成选型清单
光有比例还不够,需要把每个业务模块的读写比、峰值TPS、延迟容忍度列出来，三张表可以完成从业务到硬件的映射。
第一张表：业务模块读写统计
| 模块 | 读操作类型 | 写操作类型 | 读写比 | 峰值TPS |
|---|---|---|---|---|
| 用户中心 | 按UID点查 | 更新登录时间 | 读明显占多 | 4000 |
| 订单核心 | 查订单状态 | 创建订单、改状态 | 峰期写偏高 | 2500 |
| 报表分析 | 聚合扫描 | ETL批量写入 | 读占绝大多数 | 200 |
第二张表：硬件映射规则
- 读写比高于9:1的模块：优先内存和只读副本。
- 读写比在7:3到5:5之间：CPU、内存、NVMe均衡配置。
- 读写比低于3:7的模块：优先NVMe独立日志盘和高主频CPU。
第三张表：命令验证配置是否达标
MySQL检查磁盘写延迟：
iostat -dx 1 10
关注w_await和util，写密集库如果util长时间接近满负荷，说明磁盘已经到顶。
PostgreSQL查看缓存命中率：
SELECT sum(blks_hit) / (sum(blks_hit) + sum(blks_read)) AS hit_ratio FROM pg_stat_database WHERE datname = current_database();
读密集库命中率低于九成时,加内存比加盘更有效。
梳理读写比，选型才不会跑偏
回到开头那句话：先梳理事务读写比，再去比硬件配置，比价、比核数、比盘型号都要站在读写比的基础上才有意义，同一个读写比，在订单库和报表库身上的选型答案完全不同；同一个预算，在成都机房和云主机上的配置方案也可能差出一大截。
把现网日志统计出来,按业务模块拆开，再套到硬件映射表里，最终拿到的配置清单才是能落地的，不要用“读多写少”这种含糊描述结束，要让performance_schema和pg_stat_statements里的数字替你做决定。
Q&A：事务读写比选型常见问题
数据库服务器选型怎么评估读写比才准确？
统计至少覆盖一个完整的业务高峰周期,从慢日志和审计日志里提取SELECT、INSERT、UPDATE、DELETE的语句次数，再按事务类型归并，不要只看全天平均，要单独统计峰值时段的读写比，MySQL用performance_schema.events_statements_summary_by_digest，PostgreSQL用pg_stat_statements，都能拿到语句级数据，把写事务里的隐式读排除，比如UPDATE语句扫描的数据页不计入读请求。
订单库和报表库的读写比对比后，能不能共用一台服务器？
不建议,订单库在高峰期写入压力大，需要独立NVMe日志盘和高主频CPU，报表库主要吃内存和并行扫描能力，写入集中在夜间ETL，共用一台机器会让两类负载争抢磁盘和CPU资源，订单库的写延迟会被报表查询拖高，即使预算有限，也至少做实例级资源隔离，或者把报表库放到只读副本上。
成都地区数据库服务器配置方案里，读写比高的话要不要全上NVMe？
读比例高的模块,比如展示内容和报表查询，SATA SSD或云盘通常就能满足，把内存配大比上NVMe收益更明显，写比例高的模块，比如订单核心和流水日志，必须上企业级NVMe，并且建议独立日志盘，成都本地托管机房如果提供混合盘机型，可以把系统和日志盘用NVMe，数据盘用SATA SSD，配合读写比拆分存储层级，成本比全NVMe方案低一截，实测写入延迟也能控制在业务可接受范围。