生产环境MySQL（5.7+/8.0，InnoDB）首选XFS，因其延迟分配、extent分配机制更适配大表扩展与高并发写入；EXT4在元数据操作和SSD高IOPS下易成瓶颈。
MySQL 数据库文件系统选 XFS 还是 EXT4？XFS 更稳，尤其大表和高并发写入场景
直接结论：生产环境跑 MySQL（尤其是 5.7+、8.0，InnoDB 引擎），XFS 是更优选择。不是因为 EXT4 不能用，而是它在元数据操作、大文件扩展、并发写入路径上容易成为瓶颈。
根本原因在于 InnoDB 的典型行为：持续写 ibdata1 或独立表空间（.ibd 文件）、频繁刷 redo log（ib_logfile0/1）、大量临时表和排序操作生成的临时文件——这些都高度依赖文件系统的扩展效率与日志一致性机制。
-
XFS原生支持延迟分配（delayed allocation）+ extent-based 分配，新建/追加大文件几乎无锁，ALTER TABLE ... ENGINE=InnoDB或大批量导入时卡顿明显更少 -
EXT4默认使用journal=ordered，写.ibd文件时可能触发元数据 journal 等待，尤其在 SSD + 高 IOPS 场景下，fdatasync()延迟波动更大 -
XFS的xfs_info可直观看到allocsize（默认 64k）与swalloc（对齐优化），而EXT4的tune2fs -l输出里没有等效的“预分配提示”字段，调优入口更隐蔽
格式化前必须关掉 barrier 和 journal 模式？别乱关，只调关键项
很多人一上来就 mkfs.xfs -f -K /dev/sdb（-K 禁 barrier），或 mkfs.ext4 -O ^has_journal（干掉 journal），这反而破坏 MySQL 的 crash-safe 保证——InnoDB 依赖底层存储的 write barrier 语义来确保 redo log 刷盘顺序。
真正该调的是：让文件系统配合 InnoDB 的刷盘策略，而不是绕过它。
- XFS：用
mkfs.xfs -f -l size=128m,version=2 -d agcount=32 /dev/sdb；其中agcount（allocation group 数）设为 CPU 核数的 2–4 倍，避免多线程写同一 AG 锁争用 - EXT4：必须保留 journal，但可改模式：
tune2fs -o journal_data_writeback /dev/sdb（仅建议配合innodb_flush_log_at_trx_commit=2使用） - 两者都要禁用 atime：
mount -o noatime,nodiratime,relatime；否则每次查询都会触发元数据更新，小文件多时开销显著
挂载参数差异直接影响 fsync() 延迟，尤其在 NVMe 盘上
MySQL 的 innodb_flush_method（如 O_DIRECT）和文件系统 mount 参数是联动的。错配会导致 double buffering 或 cache 不一致，SHOW ENGINE INNODB STATUS 里常看到 log writes 平均延迟突增到 5ms+ 就是信号。
- XFS 推荐挂载：
defaults,noatime,nodiratime,logbufs=8,logbsize=256k,delaylog；其中logbufs和logbsize提升日志吞吐，delaylog允许日志延迟提交（与 InnoDB redo log 刷盘协同） - EXT4 推荐：
defaults,noatime,nodiratime,barrier=1,data=ordered；切勿用data=writeback，它会让文件数据先于元数据落盘，InnoDB crash recovery 可能失败 - 无论哪种，都禁用
commit=（EXT4）或logfreq=（XFS）这类强制定期 sync 的参数——InnoDB 自己控制节奏
线上换文件系统要停机？可以热迁移，但得绕过两个坑
不一定要停库重做。常见做法是新建 XFS 分区，用 mysqldump 或 mydumper 导出再导入，但容易忽略两件事：
- InnoDB 表空间路径硬编码在
ibdata1头部和.ibd文件头里，直接 cp 文件过去会报Tablespace is missing for table `xxx`；必须用ALTER TABLE xxx DISCARD TABLESPACE; ALTER TABLE xxx IMPORT TABLESPACE;流程 - 如果开了
innodb_file_per_table=OFF，所有表都在ibdata1里，无法单独迁移——必须先导出 SQL，再重建库，且ibdata1无法收缩，旧分区仍需保留足够空间 - 迁移后务必验证：
SELECT FILE_NAME, TABLESPACE_NAME FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE='DATAFILE';确认路径已指向新挂载点
最麻烦的从来不是格式本身，而是 InnoDB 表空间和文件系统之间那层隐式契约：谁负责原子性、谁负责对齐、谁保证顺序——没对齐，性能毛刺就是常态。
