linux文件系统挂载参数优化需配对设置：noatime与nodiratime禁用访问时间更新，nobarrier（xfs）或barrier=0（ext4）仅在有bbu/ups时启用以降延迟，ext4配data=writeback提升写吞吐，ssd加discard或定期fstrim防性能衰减。
Linux 文件系统挂载参数怎么设才不拖慢 MySQL
MySQL 在 Linux 上跑得慢，经常不是 SQL 写得差，而是文件系统默认挂载参数在“偷偷写磁盘”。noatime、nobarrier、data=writeback 这几个选项必须配对使用，否则可能白优化甚至引发风险。
-
noatime和nodiratime要一起加：禁用访问时间更新，避免每次读文件都触发元数据写入——这对高频查询的索引页访问尤其关键 -
nobarrier（XFS）或barrier=0（ext4）只在有 BBU/FBWC 的 RAID 卡或 UPS 保障下启用：它跳过写屏障，能降低约 15%~30% 的随机写延迟，但断电可能损坏文件系统 - ext4 推荐加
data=writeback：绕过日志记录数据块变更，提升写吞吐；InnoDB 自身事务日志已保证一致性，这个牺牲可接受 - SSD 环境务必加
discard或定期执行fstrim：防止长期写入后性能衰减
innodb_flush_method 该选 O_DIRECT 还是 fsync
这个参数决定 InnoDB 怎么把数据刷到磁盘。选错会导致双重缓存（OS page cache + Buffer Pool），内存浪费且 swap 风险上升。
- SSD + 内存充足（Buffer Pool ≥ 50% 物理内存）时，用
O_DIRECT：绕过 OS 缓存，让 Buffer Pool 成为唯一数据缓存层，减少内存抖动 - HDD 或内存吃紧时，保留默认
fsync：依赖 OS 缓存做合并写，缓解寻道压力 -
O_DSYNC是折中方案：只对日志文件用 direct I/O，数据文件仍走 OS 缓存，适合混合负载 - 改完要重启 MySQL，且需确认
innodb_use_native_aio = ON（Linux 默认开启）
IO 调度器和 native AIO 怎么配合生效
InnoDB 的异步 IO（native AIO）在 Linux 上不是开箱即用的，必须和底层调度器协同才能发挥效果。默认的 cfq 调度器在高并发下反而制造排队延迟。
- SSD 场景一律用
noop或deadline：前者完全由应用控制 I/O 顺序，后者按 deadline 排队，都比cfq更低延迟 - 检查当前调度器：
cat /sys/block/sdX/queue/scheduler，临时切换：echo noop > /sys/block/sdX/queue/scheduler - 永久生效需写入
/etc/default/grub：加elevator=noop参数，再update-grub && reboot - 确认 native AIO 生效：
SHOW VARIABLES LIKE 'innodb_use_native_aio'必须为ON；若为 OFF，可能是内核不支持或 libaio 未安装
从库磁盘 IO 高，哪些参数必须立刻调
主库 IO 高还能归因于业务写入，但从库 IO 高基本就是配置冗余刷盘导致的——它不对外提供写服务，没必要强持久化。
- 立刻执行：
SET GLOBAL innodb_flush_log_at_trx_commit = 2：日志写 OS 缓存，每秒刷一次，崩溃最多丢 1 秒数据，但复制一致性不受影响 - 查
log_slave_updates：如果为OFF（默认），则sync_binlog必须设为0；如果为ON，可设为10或1000 -
sync_relay_log别留默认值1：设为10000，大幅降低 relay log 刷盘频率 - 注意：
innodb_flush_log_at_trx_commit = 0在从库也禁止使用——进程崩溃会导致 relay log 和 ib_logfile 不一致，回放中断
真正卡住 IO 的往往不是单个参数，而是多个“安全默认值”叠加：比如 innodb_flush_log_at_trx_commit=1 + sync_binlog=1 + sync_relay_log=1，等于每条事务强制三次 fsync。调参前先用 iostat -x 1 看清 w_await 和 aqu-sz，否则容易在错误的方向上反复折腾。
