选对磁盘io调度器比升级硬件更有效，需按存储介质（nvme/sata ssd用mq-deadline或noop，hdd用deadline或bfq，raid/zfs用noop）和业务场景（数据库选mq-deadline，虚拟化宿主机用noop，web服务选bfq）精准匹配，并通过iostat验证r_await、w_await等指标。
选对磁盘IO调度器，比盲目升级硬件更直接有效。它不改变硬件本身，却能显著降低数据库查询延迟、提升Web服务吞吐、减少虚拟机IO抖动——关键在于匹配存储类型和业务特征。
按存储介质快速锁定调度器
现代服务器的存储类型决定调度器的底层适配逻辑，不能凭经验套用：
- NVMe SSD 或 SATA/SAS SSD：优先用 mq-deadline（内核≥4.12默认）或 noop。SSD无寻道开销，复杂排序反而增加CPU负担；mq-deadline在多队列架构下兼顾低延迟与高并发，noop则彻底交由设备主控处理，适合已启用智能缓存的RAID卡或云盘（如AWS io2、阿里云ESSD）。
- 传统机械硬盘（HDD）：选 deadline 或 bfq。deadline通过读500ms/写5s超时机制防止请求饿死，适合数据库随机IO；bfq在高负载下仍保持进程间IO公平，更适合多租户Web服务器或虚拟化宿主机。
- 纯硬件RAID、RAM盘、ZFS池：用 noop。此时IO调度已由底层固件或文件系统完成，内核再调度会造成冗余甚至冲突。
按业务负载精准匹配
同一块SSD，在不同服务下最优调度器可能不同：
- 数据库（MySQL/PostgreSQL）：mq-deadline 是当前生产首选。它默认保障读请求优先（read_expire=500），避免慢写阻塞关键查询；若需进一步压低P99延迟，可尝试 kyber（尤其搭配NVMe）。
- 虚拟化环境（KVM/LXC）：宿主机磁盘建议设为 noop。Guest OS自行调度，避免宿主与客户机双重排队导致IO放大；云厂商如AWS EBS、阿里云云盘也默认透传，无需干预。
- 高并发Web或API服务：bfq 比 deadline 更稳。当Nginx/Apache混合静态资源与动态后端调用时，bfq按预算分配IO带宽，防止日志刷盘抢占响应请求。
- 流媒体或批量备份任务：可临时切到 deadline 并调大 write_expire（如15000），让大块顺序写充分合并，提升吞吐效率。
查看与修改操作一步到位
所有调整均无需重启，但需确认生效范围：
- 查当前调度器：运行 cat /sys/block/sda/queue/scheduler，输出中方括号 [ ] 内即为激活项，例如 [mq-deadline] kyber bfq noop。
- 临时切换（重启失效）：用 root 执行 echo kyber > /sys/block/sda/queue/scheduler；注意部分NVMe设备仅支持 noop/kyber，写入失败会报错。
- 永久生效：推荐用 udev 规则按设备精确控制，例如创建 /etc/udev/rules.d/60-io-scheduler.rules，内容为：ACTION=="add|change", KERNEL=="sda", ATTR{queue/scheduler}="mq-deadline"；避免全局 elevator= 参数影响其他设备。
验证效果再上线
改完不验证，等于没改。重点观察三项指标：
- 用 iostat -x 1 查看 r_await 和 w_await 是否下降（单位毫秒），降幅明显说明调度生效；
- 关注 %util 是否持续接近100%且 avgqu-sz 稳定——说明队列深度合理，未出现堆积或空转；
- 业务层同步测试：数据库执行 SELECT BENCHMARK(1000000,ENCODE('test','salt'))，对比平均响应时间变化。
