MySQL 8.0启动失败报“IO scheduler mismatch”等问题，根本原因是Linux内核I/O调度器未适配SSD/NVMe：NVMe需设为none、SATA SSD设为noop，否则mq-deadline等HDD调度器会引入额外延迟；多盘需分别配置，Windows下则需关闭Defender实时防护、禁用NTFS日志并避免UAC路径。
MySQL 8.0启动失败报“IO scheduler mismatch”或卡在初始化阶段
这不是MySQL本身的错误，而是Linux内核I/O调度器与SSD/NVMe硬件特性不匹配导致的隐性阻塞。MySQL进程能跑起来，但innodb_buffer_pool_size稍大一点就卡住、mysqld --initialize超时、或者iostat显示w_await飙升但%util很低——这些都指向调度器没关对。
- 确认当前调度器：
cat /sys/block/nvme0n1/queue/scheduler（NVMe）或cat /sys/block/sda/queue/scheduler（SATA SSD），输出类似[mq-deadline] none，方括号里的是当前生效项 - SSD必须设为
none（NVMe）或noop（SATA SSD），mq-deadline或kyber是给HDD设计的，会引入额外队列延迟 - 临时生效（重启失效）：
echo none > /sys/block/nvme0n1/queue/scheduler - 永久生效：写udev规则，避免被systemd或内核更新覆盖：
ACTION=="add|change", KERNEL=="nvme*[0-9]", ATTR{queue/scheduler}="none"→ 保存为/etc/udev/rules.d/60-ssd-scheduler.rules，然后udevadm control --reload-rules && udevadm trigger - 别漏掉多盘场景：如果
datadir和innodb_log_group_home_dir不在同一块盘上，两块盘都要单独设调度器
Windows下MySQL 8.0安装卡在“initializing database”且日志报文件读取失败
Win11里看到mysqld.exe initializing of server in progress卡死几十秒，最后报file '.\xxx.bin.index' not found或data directory is unusable，大概率不是权限问题，而是NTFS日志+防病毒软件触发了同步I/O放大。
- 关闭Windows Defender实时防护（临时）：设置 → 隐私和安全 → Windows 安全中心 → 病毒和威胁防护 → 管理设置 → 关闭“实时保护”
- 禁用NTFS日志：以管理员身份运行
fsutil behavior set disablelastaccess 1，再执行fsutil behavior set disablelastaccess 0强制刷新（部分Win11版本需此步） - 确保
datadir路径无中文、无空格、非C:\Program Files这类受UAC限制目录；推荐用D:\mysql\data这种直白路径 - 初始化时加
--console参数直接看输出：mysqld --initialize --console --basedir=D:\mysql --datadir=D:\mysql\data，比静默安装更容易捕获ERROR 1045或OS errno 13类底层I/O拒绝 - 别用压缩包解压版直接双击
mysqld.exe：它会尝试以当前用户权限读写AppData临时目录，而那里默认禁止写入；必须用命令行指定--datadir
MySQL 8.0配置了innodb_flush_method=O_DIRECT却启动失败
这个参数一加就报错退出，常见于Rocky Linux 9或CentOS Stream，本质是SELinux或文件系统挂载选项冲突，不是MySQL配置错。
- 先验证是否真需要
O_DIRECT：仅当innodb_buffer_pool_size> 2G且磁盘是SSD/NVMe时才启用；HDD或小内存机器设了反而降低吞吐 - 检查挂载选项：
mount | grep " /var/lib/mysql "，确认输出含noatime,nobarrier（XFS）或noatime,barrier=0（ext4），缺一不可 - SELinux必须放行：
chcon -R -t mysqld_db_t /var/lib/mysql，若用自定义路径如/ssd/mysql，则先semanage fcontext -a -t mysqld_db_t "/ssd/mysql(/.*)?"再restorecon -Rv /ssd/mysql - Rocky Linux 9默认启用
kernel.randomize_va_space=2，可能干扰O_DIRECT内存映射，临时测试可echo 1 > /proc/sys/kernel/randomize_va_space，长期方案是升级到MySQL 8.0.33+（已修复） - 若仍失败，改用
innodb_flush_method=fsync回退，虽有双重缓存开销，但至少能跑通
为什么调了innodb_io_capacity但iostat看不出变化？
这个参数只控制InnoDB后台刷脏页节奏，不影响单条SQL的I/O行为。你看到w_await没降、tps没升，不代表参数无效，只是它根本不管前台请求。
-
innodb_io_capacity生效前提：必须配合innodb_adaptive_flushing=ON（MySQL 8.0默认开），否则该值被忽略 - 典型值参考：
innodb_io_capacity=2000（SATA SSD）、4000（入门级NVMe）、12000（企业级NVMe），但必须实测：用fio跑--name=randwrite --ioengine=libaio --bs=16k --iodepth=64 --runtime=60得到随机写IOPS，再乘0.7～0.8 - 别只调
innodb_io_capacity：必须同步设innodb_io_capacity_max = innodb_io_capacity * 2，否则突发写入时刷盘跟不上，buffer pool迅速淤积脏页 - 验证是否生效：
SHOW ENGINE INNODB STATUS\G里找Buffer pool hit rate和Pages flushed每秒数值，调高后后者应明显上升，前者稳定在99%+才说明有效 - 云盘用户注意：AWS gp3、阿里云ESSD有IOPS配额，盲目调高
innodb_io_capacity超出配额只会让await暴涨，先查控制台实际配额再设
真实I/O瓶颈往往藏在innodb_buffer_pool_size和innodb_io_capacity的组合失配里——前者决定“要不要读盘”，后者决定“读得多快”。两个参数差一个数量级，监控指标就会互相矛盾。
