在主从复制架构里，从库服务器的顺序读吞吐能力，核心要看存储介质的顺序读带宽，而不是随机读写IOPS，NVMe固态硬盘是现阶段的最优解，机械硬盘仅在成本极度敏感且查询量可控的场景下还有存在价值。
从库的日常：为什么顺序读吞吐会卡脖子
主从复制架构里，从库的角色本来就不太“体面”，主库负责写入，压力在随机写和事务处理；从库负责读出，压力在查询扫描和日志回放，很多人给从库配机器时，习惯性照搬主库的规格，结果发现钱花了,查询该慢还是慢。
从库的读压力，多数情况下是两类负载构成的，第一类是业务侧直接把大查询、报表分析、后台批量任务扔到从库上，这类SQL往往要扫好几百万行甚至上千万行数据，第二类是binlog回放，主库的写入日志同步到从库后，从库要串行执行这些变更，这个过程的本质是顺序写盘加随机更新内存页，但日志本身的读取和落盘,同样依赖顺序带宽。
问题就出在这里，顺序读吞吐不够，大查询的扫描速度就上不去，你给从库配了一堆高主频CPU，结果存储介质喂不上数据，CPU在那儿空转,这就是典型的瓶颈错配。
顺序读吃的是带宽，不是IOPS
业内专家指出，很多人在选型时过分关注IOPS这个指标，这在从库场景下是个常见的认知偏差，随机读才吃IOPS，顺序读吃的是带宽，单位是MB/s或者GB/s，你拿一块标称IOPS很高的企业级SATA固态，去跑顺序读，带宽上限也就550MB/s左右，跟一块普通SATA固态拉不开差距，而顺序读吞吐能力的真实差异,体现在接口协议和通道数上。
两块盘的对比数据能直观说明问题：
| 存储介质 | 顺序读带宽典型值 | 随机读IOPS典型值 | 核心适用场景 |
|---|---|---|---|
| 7200转机械盘 | 150-200MB/s | 100左右 | 归档、冷数据备份 |
| SATA固态 | 500-550MB/s | 50000-90000 | 普通OLTP读业务 |
| 企业级NVMe固态 | 3000-7000MB/s | 100万以上 | 从库高并发查询、大数据量扫描 |
从库如果跑的是报表类、分析类的SQL，机械盘那不到200MB/s的顺序读带宽，意味着扫一张10GB的表，纯读取时间就要超过50秒，NVMe固态只需要2到3秒。
从库服务器配置固态还是机械硬盘，先想清楚顺序读吞吐到底吃的是哪一项
这个问题在技术社区里反复被问，我的建议是别先看价格,先看你的从库在架构里的实际定位。
- 定位是实时性备份节点，主库挂了能顶上就行，那么机械盘加RAID阵列，顺序读能过600MB/s,勉强能接受。
- 定位是承担大部分读流量，尤其是报表、导出、聚合这类重活,那么NVMe固态基本是唯一选择。
- 定位是读写分离架构里的专用分析节点，业务方动不动跑个一小时的大任务，那不仅需要NVMe固态,还需要关注PCIe通道数和盘位数量。
机械盘在从库场景的生存空间被挤压了多少
机械盘现在并非完全没有生存空间，但生存空间非常窄，统计下来，近年新建的读写分离架构里，从库采用纯机械盘的比例已经降到比较低的水平，原因很简单，机械盘的顺序读带宽天花板太明显了，即便用8块盘组RAID0，顺序读带宽也就1GB/s出头，而一块消费级NVMe固态就能跑满这个数,还不用考虑多盘故障率叠加的问题。
机械盘真正还能发挥价值的地方是温备节点和归档节点，这类从库不直接响应业务查询，只需要保证数据同步不中断，偶尔做一次全量恢复演练，这种情况下，顺序读吞吐能力要求不高,机械盘的每GB成本优势才值得被考虑。
顺序读吞吐能力不是从库选配的唯一依据，但它是第一依据
我们可以把从库的硬件选型拆成三个维度：存储、CPU内存、网络，在多数的读写分离架构讨论帖里，大家更常聊的是“从库服务器配置固态还是机械硬盘”这类存储问题,这本身就说明存储介质是大家心里的头号困惑。
实际部署时,我建议按这样的优先级来决策。
第一优先级：存储介质的顺序读带宽
先计算你的从库需要承受多大的读吞吐，比如业务上有20个固定报表任务，每个任务平均扫描5GB数据量，要求在30秒内完成，那么至少需要4GB/s的有效顺序读带宽，加上日常的在线查询流量，乘以一个冗余系数,就得出存储层的目标带宽。
目标带宽确定后,选择就清晰了：
- 顺序读需求不高于1GB/s，SATA固态阵列可以满足,成本可控。
- 顺序读需求在1GB/s到3GB/s之间，选单块企业级NVMe固态,或者两块做RAID1。
- 顺序读需求超过3GB/s，需要多块NVMe固态组阵列,同时注意CPU的PCIe通道数是否支持。
第二优先级：CPU核数和内存容量
存储带宽决定了数据能不能进来，CPU和内存决定了进来的数据能不能快速处理，从库的查询大多是聚合、关联、排序这类计算密集操作，经验值参考：每1GB/s的顺序读吞吐，至少配8个物理核心，内存则主要给InnoDB缓冲池，建议按目标热数据集的30%到50%来规划。
第三优先级：网络带宽
这块经常被忽略，从库的网络吞吐必须大于存储的顺序读带宽，否则所有查询都会卡在网络上，万兆网卡在从库场景里建议作为标配,否则存储性能再强也是白搭。
MySQL从库顺序读优化的实际排查路径
如果你的从库已经部署了NVMe固态，顺序读吞吐还是上不去，问题往往不在硬件，而在软件层,下面是一套可直接落地的排查路径。
确认磁盘队列深度有没有压满
顺序读场景，磁盘队列深度上不去，吞吐必然受限，Linux下用iostat -x 1观察avgqu-sz和%util指标。%util跑到100%但avgqu-sz很低，说明IO调度器对请求合并不够激进，检查/sys/block/nvme0n1/queue/scheduler，确认用的是none或noop，而不是cfq。cfq调度器会引入大量不必要的寻址延迟,在NVMe设备上极度影响顺序读吞吐。
检查预读参数
Linux的预读窗口对顺序读性能有直接影响，默认的read_ahead_kb是128KB，这个值太小，从库大表扫描场景，建议调大到4096KB。
blockdev --setra 4096 /dev/nvme0n1
MySQL层面，innodb_buffer_pool_size越大，越有机会把索引页和数据页留在内存里，减少物理顺序读的次数，但这改变不了大查询必须扫盘的事实,所以存储层的吞吐才是根基。
单表扫描测试验证实际带宽
不确定瓶颈在哪，就直接测，用MySQL的SELECT COUNT()扫一张大表，同时用perf或者pidstat看进程状态，如果CPU的wait占比高，说明存储喂不满CPU；如果CPU跑满但是带宽没上去，说明SQL本身的执行计划有问题,走了全表扫但过滤效率太低。
主从复制架构下从库选服务器的核心就俩字：带宽
回到最开始的问题，主从复制架构下，从库服务器侧重顺序读吞吐能力，本质上是在回答一个选型问题：怎么让数据以最快的速度从盘上流入内存，再交给CPU，这个过程的物理极限就是存储介质的顺序读带宽，机械把上限焊死在了几百兆，SATA固态把上限推到500MB左右,NVMe固态则把这个上限抬到了GB级。
所以结论很直接：从库顺序读吞吐优先，NVMe固态是确定性选择，如果你的预算确实紧张，可以考虑机械盘做冷备节点，但不要指望它扛起任何实质性的查询流量，主从复制本身就意味着主库性能再高,从库跟不上也会拖慢整体架构的可用性。
主从复制架构的从库就一定会做大量顺序读吗
不一定，上面说的顺序读，前提是你的从库真的承担了分析型查询，在很多简单的读写分离架构里，从库的查询都是走主键索引的点查，这类负载是随机读特征，这时候再纠结顺序读吞吐就有点舍本逐末了，先确认你的从库到底在跑什么类型的SQL，再做硬件决策，顺序读吞吐能力是从库存储选型的第一依据,但不是所有从库的第一依据。
从库使用机械硬盘后会遇到什么具体问题
主从复制架构的从库如果机械硬盘，最容易遇到的问题是复制延迟和查询超时叠加出现，binlog回放是顺序写，机械盘能应付，但一旦有大查询在扫盘，磁盘臂要在顺序写和顺序读之间反复切换，实际带宽会明显下滑，延迟一高，主从数据不一致的时间窗口拉长，业务侧读到旧数据的概率增加，而大查询本身也会因为存储竞争变得极慢，形成恶性循环，行业内普遍认同，从库的存储性能冗余系数至少要留到1.5倍。
如何验证当前从库的顺序读吞吐是否达标
最简单的办法，用fio在从库数据目录所在的文件系统上跑一轮顺序读基准测试，注意不要在生产数据盘上直接跑，在从库上临时挂一块独立磁盘来测，或者用fio的directory参数指向一个专门的测试目录,命令参考如下：
fio --name=seqread --rw=read --bs=1M --size=10G --numjobs=4
--iodepth=32 --direct=1 --ioengine=libaio
--group_reporting
看输出的READ: bw=xxxxMiB/s，如果这个数值远低于你购买磁盘的标称顺序读带宽，先排查PCIe链路速率、磁盘固件、以及是否插在了非CPU直连的通道上，在云服务器上跑这个测试时，注意先确认云厂商实例规格里标注的最大顺序读带宽，实例规格页面上写的“最大内网带宽”和“最大顺序读吞吐”是两个不同概念，前者是网络,后者才是决定从库SQL执行速度的关键。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/640004.html
