MySQL在SSD上出现IO等待，主因是InnoDB未适配SSD：参数沿用HDD配置、I/O调度器未关闭、日志刷盘策略不匹配；需验证redo刷盘瓶颈、关闭调度器、启用O_DIRECT、调优io_capacity与log_file_size、检查挂载参数及缓冲池命中率。
MySQL在SSD上仍有IO等待，大概率不是盘不够快，而是InnoDB没用对SSD——参数沿用HDD配置、I/O调度器未关闭、日志刷盘策略与硬件不匹配，这三类问题占了八成以上。
确认是不是真被SSD IO卡住
别一看到await升高或%util打满就调参。先验证瓶颈是否真实落在SSD写入路径上：
- 执行
SHOW ENGINE INNODB STATUS\G，翻到LOG段，看Log sequence number和Log flushed up to差值是否持续扩大（> 1GB说明redo刷不过来） - 查状态变量：
SHOW GLOBAL STATUS LIKE 'innodb_os_log_pending_fsyncs'，长期>0就是redo fsync排队 - 运行
iostat -x 1，盯紧你SSD设备（如nvme0n1）的await：SSD下超过2ms就要警惕，超过5ms基本确认是刷盘瓶颈 -
SHOW PROCESSLIST里大量线程卡在Updating或Writing to net，但CPU和内存使用正常，这是典型IO阻塞表现
关掉I/O调度器并验证O_DIRECT生效
SSD不需要机械盘那套调度逻辑，Linux默认启用的cfq或deadline反而会引入额外延迟和IO放大。
- 查当前调度器：
cat /sys/block/nvme0n1/queue/scheduler（把nvme0n1换成你的设备名） - 临时切为
none（NVMe）或noop（SATA SSD）：echo none > /sys/block/nvme0n1/queue/scheduler - 永久生效需改
/etc/default/grub，在GRUB_CMDLINE_LINUX加elevator=none，再update-grub && reboot -
innodb_flush_method必须设为O_DIRECT：绕过OS page cache，否则InnoDB buffer pool和系统cache双重缓存，浪费内存还拖慢SSD带宽 - 验证是否真绕过page cache：
strace -e trace=io_submit,writev -p $(pgrep mysqld)，看到io_submit而非writev才说明O_DIRECT生效
重设innodb_io_capacity与innodb_log_file_size
默认innodb_io_capacity=200是给HDD设的，SSD下这个值等于自废武功；而innodb_log_file_size太小会导致前台强制刷脏页，直接卡住事务提交。
- 用fio测实测随机写IOPS：
fio -name=randwrite -ioengine=libaio -bs=16k -iodepth=64 -runtime=60 -filename=/path/on/ssd/testfile -
innodb_io_capacity设为实测IOPS × 0.7～0.8（例如实测120K → 设90000），innodb_io_capacity_max设为前者的1.5～2倍 -
innodb_log_file_size总和建议为innodb_buffer_pool_size的25%左右（如Buffer Pool 21G → 总log大小≈5G，两个文件各2.5G） - 调整log file size必须停库：先
SET GLOBAL innodb_fast_shutdown = 0，停MySQL，删旧log文件，改配置，再启 - 同时检查
innodb_flush_neighbors=0（SSD关闭邻接页刷新）、innodb_use_native_aio=ON（Linux异步IO必需）
别忽略挂载参数和云盘配额陷阱
很多“SSD还是慢”其实是文件系统层或云环境限制导致的，跟InnoDB本身关系不大。
- 确认SSD挂载时含
noatime,nodiratime,barrier=0（XFS/ext4），否则元数据写入仍在拖慢SSD - 查
mount | grep /var/lib/mysql，确保innodb_log_group_home_dir指向SSD路径，且MySQL用户对该路径有读写权限 - 云主机（如阿里云RDS、AWS RDS）可能不支持
O_DIRECT或已锁定内核参数，得看厂商文档；有些ESSD/gp3实例有IOPS配额上限，盲目调高innodb_io_capacity无效 - 避免把redo log、binlog、数据文件全放在同一块SSD上——它们的IO模式冲突（顺序写 vs 随机读写），物理分离才能榨干SSD带宽
最常被跳过的点是：没验证innodb_buffer_pool_size是否真的够大。SSD再快，如果缓冲池命中率低于99%，热数据还在反复进出磁盘，所有调优都是白忙——先看Innodb_buffer_pool_reads和Innodb_buffer_pool_read_requests算出命中率，再决定要不要调大。
