生产环境mysql ssd必须按数据生命周期、i/o特性和故障隔离三重逻辑分挂载点：/data/mysql（数据与redo）、/data/binlog（顺序写）、/data/tmp（临时文件）、/data/undo（独立undo），禁用numa、设i/o调度器为none/noop，挂载加noatime,nobarrier，启用trim，并验证inode使用率。
生产环境 MySQL 的 SSD 磁盘挂载点不能只图“快”，必须按数据生命周期、I/O 特性、故障隔离三重逻辑来切分。盲目把所有目录塞进一个 /data 分区，等于把日志、临时文件、binlog 和数据文件绑在同一块物理介质上，一旦写满或出现坏块，整个实例可能连锁崩溃。
为什么不能只用一个挂载点？
MySQL 各类路径的 I/O 行为差异极大：
-
/var/lib/mysql：随机读写密集（InnoDB 数据页、redo log 刷盘），对延迟极度敏感 -
/var/log/mysql（或自定义 binlog 目录）：顺序追加写为主，但需高吞吐和持久化保障（影响主从同步与恢复） -
/tmp或tmpdir：大量排序、临时表、JOIN 中间结果，突发性大文件写入，易触发磁盘爆满 -
/var/lib/mysql/undo_001（若独立配置）：长事务 undo 日志，写入频率低但不可丢，需与数据目录同级可靠性
共用挂载点会导致：tmpdir 写爆磁盘 → redo log 刷盘失败 → 实例 crash；binlog 归档卡住 → 主从延迟飙升；单一分区坏扇区 → 全库不可用。
推荐的 SSD 挂载点划分方案（4 分区最小可行集）
以一块 1TB NVMe SSD 为例，不追求绝对比例，而按角色隔离：
-
/data/mysql（约 60% 容量，如 600G）：仅挂载datadir（即/var/lib/mysql），存放 ibdata1、ib_logfile*、.ibd 文件。必须启用innodb_flush_method=O_DIRECT，绕过 OS 缓存直写设备。 -
/data/binlog（约 20%，如 200G）：挂载log_bin和relay_log路径。建议关闭sync_binlog=0（依赖 OS 刷盘）或设为1（强一致性，性能略降），并确保该分区使用noatime,nobarrier挂载选项提升吞吐。 -
/data/tmp（约 10%，如 100G）：挂载tmpdir。必须设置tmp_table_size和max_heap_table_size≤ 512M，防止内存表溢出后疯狂写磁盘。建议用ext4+mount -o noatime,nodiratime减少元数据更新开销。 -
/data/undo（约 10%，如 100G）：若启用了独立 undo 表空间（innodb_undo_directory=/data/undo），此处专用于存储 undo_*.ibd。避免与数据目录混放，降低恢复时 undo 损坏风险。
Linux 系统层关键配置要点
挂载本身只是第一步，以下配置直接影响 SSD 寿命与 MySQL 稳定性：
- 禁用 NUMA：在 BIOS 或内核启动参数中加
numa=off，SSD 对 NUMA 敏感度低，开启反而导致跨节点内存访问延迟升高 - I/O 调度器选
none（NVMe）或noop（SATA SSD）：现代 SSD 自带控制器调度，内核调度器纯属冗余 -
/etc/fstab示例片段：UUID=xxx /data/mysql xfs defaults,noatime,nodiratime,inode64,swalloc 0 2 UUID=yyy /data/binlog xfs defaults,noatime,nobarrier 0 2
- 确认 SSD TRIM 已启用：
sudo fstrim -v /data/mysql，并加入cron每周执行（XFS 默认支持 online discard）
容易被忽略的兼容性陷阱
很多团队在测试环境用得好好的方案，上线就出问题，往往栽在这几个点：
- Docker 容器内挂载：宿主机已按上述方式分区，但容器启动时只挂载了
/data/mysql，tmpdir仍落在容器 overlayfs 层 → 必须显式传入-v /data/tmp:/tmp - SELinux 强制策略：CentOS/RHEL 上新挂载点默认无 MySQL 上下文标签，
chcon -R -t mysqld_db_t /data/mysql必做，否则启动报Permission denied - MySQL 8.0+ 的
innodb_redo_log_capacity：若未显式设置，会自动根据datadir所在磁盘大小分配 redo log 总容量，挂载点太小会导致频繁 checkpoint，反拖慢性能 - 备份工具（如 Percona XtraBackup）默认只备份
datadir：binlog和undo分区需单独纳入备份脚本，否则 PITR（时间点恢复）失效
最常被跳过的动作是：没验证各挂载点的 df -i（inode 使用率）。SSD 小文件多的场景（比如高频率创建临时表），inode 耗尽比磁盘空间耗尽更快，且错误提示极不直观——表现为 Can't create/write to file，但 df -h 显示空间充足。
