磁盘规划需分离数据与日志、预留 30% 余量、匹配 IO 特性：data 目录独占 SSD，binlog 与 redo log 共用低延迟 SSD，大对象表可单独挂载；启用 innodb_file_per_table，禁用共享表空间；严格限制日志大小并轮转。
MySQL 环境搭建时，磁盘规划直接影响性能、稳定性和后期维护成本。核心原则是：分离关键路径、预留增长空间、匹配 IO 特性。
数据目录与日志目录必须物理分离
将 red”>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等趋势判断写入压力 - 自动清理脚本应作用于归档日志和旧备份，而非线上数据目录
