MySQL安装包解压后约300–600 MB，精简部署可压至200 MB以内；data目录初始10–20 MB，但实际增长受ibdata1、ibd文件、binlog、日志及tmpdir影响；内存配置不当会加剧磁盘占用；SSD与HDD对空闲空间要求不同，且需关注inode耗尽风险。
MySQL安装包和基础二进制文件占多少空间
MySQL官方社区版（如 8.0.x）的压缩包解压后，bin、lib、share 等目录加起来通常在 300–600 MB 左右，取决于是否启用调试符号或包含文档。精简部署（仅保留 mysqld、mysql、必要插件和字符集）可压到 200 MB 以内。
注意：data 目录不包含在安装包内，它会在首次初始化时生成，初始大小约 10–20 MB（含系统表、默认时区、performance_schema 表结构等）。
数据目录（data dir）的真实增长逻辑
真正吃空间的是 data 目录，但它的增长不是线性的，也不只看表数据量：
-
ibdata1（如果用共享表空间）会持续追加，即使删了表也不会自动收缩 -
.ibd文件（独立表空间）删除表后空间可被 InnoDB 回收，但不会返还给操作系统，除非执行ALTER TABLE ... ENGINE=InnoDB或OPTIMIZE TABLE - 二进制日志（
binlog）默认不自动清理，expire_logs_days设为 0 就永远累积 - 慢查询日志、错误日志若未轮转，可能单个文件达 GB 级
-
tmpdir指向的临时目录，在大排序、大连接、GROUP BY 或 DISTINCT 时可能突发占用数十 GB
内存与磁盘空间的隐性耦合关系
MySQL 不是“只占磁盘”的服务——内存配置直接影响磁盘行为：
-
innodb_buffer_pool_size太小 → 频繁刷脏页 → 增加ib_logfile切换频率和写放大 -
sort_buffer_size/read_rnd_buffer_size过大 → 单连接可能在tmpdir写临时文件，触发磁盘爆满 - 没开
innodb_file_per_table→ 所有表挤在ibdata1，后续想收缩必须导出再导入，期间需要 2 倍原始数据空间 作中转
举例：一个 50 GB 的库，若要迁移并启用独立表空间，临时空间预留至少 100 GB 是保守估计。
SSD 与 HDD 对空间规划的差异化影响
硬件类型不改变总容量需求，但显著改变“安全余量”底线：
- HDD：建议空闲空间 ≥ 总数据量的 40%，避免碎片化导致
ALTER TABLE失败或UNDO扩展卡住 - SSD：可压到 15–20% 空闲，但要注意厂商标称容量（如 1 TB SSD 实际可用约
930 GB），且部分型号在写满 90% 后性能断崖下降 - 务必避开“系统盘 + MySQL data 同盘”：
/var/log、/tmp、mysqld.sock和data共用根分区，一个日志打满就导致 MySQL 挂起
最常被跳过的一步：检查 df -i —— 小文件多的场景（比如每行存一张缩略图的 BLOB 表），inode 耗尽比磁盘满更早发生，且错误提示极不直观（常表现为 Can't create table 或 OS error code 28: No space left on device）。
