磁盘规划需分离数据与日志、预留30%余量、匹配IO特性：data目录独占SSD，binlog与redo log共用低延迟SSD，大对象表可单独挂载；启用innodb_file_per_table，禁用共享表空间；严格限制日志大小并轮转。
MySQL环境搭建时，磁盘规划直接影响性能、稳定性和后期维护成本。核心原则是：分离关键路径、预留增长空间、匹配IO特性。
数据目录与日志目录必须物理分离
将data目录（表数据、索引）、binlog、redo log、slow query log等分别挂载到不同物理磁盘或LVM逻辑卷上。避免I/O争抢——例如redo log写入频繁且顺序，而数据文件读写随机性高，混在同一磁盘会互相拖慢。
- 推荐方案：data目录单独一块SSD；binlog和redo log共用另一块低延迟SSD（或NVMe）；备份临时目录挂载到大容量HDD
- 若仅有一块盘，至少用不同分区（如
/var/lib/mysql和/var/log/mysql），并确保innodb_log_group_home_dir指向独立路径
InnoDB表空间按用途分盘管理
启用innodb_file_per_table=ON（默认已开启），让每张表有独立.ibd文件，便于单表迁移、收缩和监控。但系统表空间（ibdata1）仍需关注：
- 若使用共享表空间，务必为
ibdata1所在路径预留足够空间（建议≥50GB起），它会持续增长且无法在线收缩 - 新建实例强烈建议关闭共享表空间，改用独立表空间+定期归档冷数据
- 对于大字段（BLOB/TEXT）多的业务，可考虑将
innodb_file_per_table开启，并把大对象表单独挂载到高吞吐磁盘
日志类文件严格限制大小与轮转策略
binlog、redo log、error log不是“放任自流”的文件，必须主动管控：
-
binlog：设置
expire_logs_days = 7（或binlog_expire_logs_seconds = 604800），配合max_binlog_size = 1G控制单文件体积 -
redo log：总大小建议为可用内存的25%~50%（如64GB内存配16~32GB redo log），通过
innodb_log_file_size × innodb_log_files_in_group计算，修改需停库 - slow log / general log：非调试期建议关闭；开启时指定独立路径，并用logrotate每日切分压缩
预留至少30%磁盘余量，监控要前置
MySQL对磁盘满异常敏感：写入阻塞、主从中断、甚至实例崩溃。不能依赖“快满了再扩容”：
- 初始分配空间建议按1年增长预估，再上浮30%缓冲（例如预估年增200GB → 分配260GB以上）
- 在Zabbix/Prometheus中配置
df -h监控 + MySQL内建指标Information_schema.INNODB_METRICS中log_data_written等趋势判断写入压力 - 自动清理脚本应作用于归档日志和旧备份，而非线上数据目录
