优化Linux磁盘调度算法关键在于匹配设备类型、内核版本与负载：NVMe/SATA SSD（≥5.0内核）首选mq-deadline，HDD适用mq-deadline或deadline，纯硬件RAID等才用none；通过cat /sys/block/设备名/queue/scheduler查看，echo临时切换，GRUB配置永久生效，避免统一硬编码。
优化 Linux 系统的磁盘读写调度算法，关键不是“换一个调度器就变快”，而是根据设备类型、内核版本和实际负载选对策略，并配合基础配置一起调。
先确认设备类型和当前调度器
调度器是按块设备单独设置的（比如 sda 和 nvme0n1 可以不同），不能一概而论：
- 查当前值：运行
cat /sys/block/设备名/queue/scheduler（如cat /sys/block/nvme0n1/queue/scheduler），输出中 方括号内 的是生效项 - NVMe 设备显示
[none]是正常现象，不代表没调度，而是由硬件或 blk-mq 层接管 - 内核 ≥ 5.0 推荐优先试 mq-deadline；CentOS 7 等旧系统（内核 3.10）只能用 deadline
按设备类型选合适的调度器
盲目套用“SSD 用 noop”已过时，现代内核下更看重队列模型匹配：
-
NVMe 或 SATA SSD（内核 ≥ 5.0）：首选
mq-deadline—— 它支持多队列、能合并请求、防饿死，数据库随机读写实测比 noop 降低 10%~15% 的 99 分位延迟 -
HDD（机械盘）：仍适用
mq-deadline（新内核）或deadline（老内核），它兼顾吞吐与延迟，比 CFQ 更稳 -
纯硬件 RAID 卡、ramdisk、或云平台明确声明底层已调度（如 AWS EBS 优化实例）：才考虑
none或noop - CFQ 已在主流发行版中被弃用，不建议用于服务器或数据库场景
临时改 vs 永久改：怎么操作才可靠
临时修改只影响当前会话，永久修改需进启动流程，但方式有讲究：
- 临时生效（测试用）：
echo mq-deadline > /sys/block/sda/queue/scheduler（需 root 权限） - 永久生效（推荐 GRUB 方式）：
• 编辑/etc/default/grub，在GRUB_CMDLINE_LINUX_DEFAULT行末加elevator=mq-deadline
• 运行update-grub（Debian/Ubuntu）或grub2-mkconfig -o /boot/grub2/grub.cfg（RHEL/CentOS） - 避免用
/etc/rc.d/rc.local：设备名可能尚未初始化，脚本静默失败 - 别给所有盘统一设同一个调度器：系统盘用
mq-deadline，USB 外置 SSD 或虚拟机磁盘可能更适合none
参数调优：多数情况不用动，真要调得懂风险
默认参数对大多数场景已足够稳健，乱调反而引入问题：
-
read_expire（读超时，默认 500ms）和write_expire（写超时，默认 5s）一般不动——调太短会频繁派发、抬高延迟；调太长会让大日志阻塞其他请求 -
nr_requests（队列深度）可微调：高并发随机读写场景（如 PostgreSQL OLTP）可适当增大（如从默认 256 改为 512），但需观察 I/O 吞吐与延迟变化 - 调整前建议用
iostat -dx 1或iotop基线对比，避免“优化”成降级
