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）。
