查 information_schema.TABLES 是最准的磁盘空间评估方式，它反映数据文件（.ibd）和表结构的真实大小，而非逻辑行数；需结合 innodb_file_per_table 配置判断准确性。
怎么看当前数据库实际占用的磁盘空间
直接查 information_schema.TABLES 是最准的，它反映的是数据文件（.ibd）和表结构（.frm 或数据字典）的真实大小，不是内存或缓存里的“逻辑行数”。别只看 SELECT COUNT(*)，那跟磁盘无关。
常用语句：
SELECT
table_schema AS db,
table_name AS tbl,
ROUND((data_length + index_length) / 1024 / 1024, 2) AS size_mb
FROM information_schema.TABLES
WHERE table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
ORDER BY size_mb DESC
LIMIT 20;-
data_length是数据页实际占用（含碎片），index_length是索引页大小，加起来才是磁盘开销主体 - 如果某张表
size_mb远大于AVG_ROW_LENGTH * TABLE_ROWS，说明存在严重碎片，后续可能突然膨胀 - 注意：开启
innodb_file_per_table=OFF时，所有表共用ibdata1，information_schema无法准确拆分单表大小，必须先确认该配置
怎么预估未来半年的磁盘增长量
靠静态行数乘以平均长度会严重失真——因为 B+ 树分裂、事务 undo log、redo 日志循环写入、临时排序/聚合产生的磁盘 IO 都不体现在表大小里。得从写入链路分层估算。
- 主业务表：按日均新增行数 × 行平均物理大小（建议用
AVG_ROW_LENGTH× 1.3 系数补碎片）× 天数 - binlog：按日均 DML 量 × 平均每条事件体积（简单更新约 200–500B，含大字段则翻倍），再乘保留天数（
expire_logs_days） - undo log：如果长事务多或
innodb_undo_log_truncate=OFF，undo 表空间可能持续增长，需监控INFORMATION_SCHEMA.INNODB_METRICS中undo_log_written - 临时文件：大
GROUP BY、ORDER BY、CREATE TEMPORARY TABLE会写磁盘到tmpdir，高峰期可能占几十 GB，但通常不持久
哪些操作会导致磁盘空间“突然暴涨”且不易察觉
不是所有增长都来自 INSERT。很多 DBA 在凌晨收到磁盘告警，一查发现是某个维护操作触发了隐式扩容。
-
ALTER TABLE ... ADD COLUMN（尤其非 NULL + DEFAULT）在旧版本 MySQL（.ibd 文件，瞬时翻倍 -
OPTIMIZE TABLE本质也是重建，且新表建完才删旧表，期间双倍空间占用 - 大事务回滚：未提交的长事务一旦回滚，undo log 要重放，同时可能生成大量临时中间页
- 开启
innodb_file_per_table=ON后，DROP TABLE不会立即释放磁盘空间给 OS，只是标记为可复用；要用OPTIMIZE TABLE或重启 mysqld 才能回收（取决于innodb_file_per_table和innodb_fast_shutdown）
监控和告警该盯住哪几个关键指标
光看 df -h 太晚了。真正要提前干预的是 InnoDB 内部水位和日志写入速率。
- 磁盘使用率阈值不能设死 85%，得结合增长斜率：用 Prometheus +
node_filesystem_avail_bytes做线性拟合，预测 72 小时后是否触线 - 关键 SQL 监控：
SHOW ENGINE INNODB STATUS\G里的FILE I/O段，看pending normal aio reads/writes是否持续 > 0，说明 I/O 已成瓶颈，空间写入可能卡住 - 检查
innodb_data_pending_fsyncs和innodb_buffer_pool_pages_dirty比例，若脏页占比长期 > 70% 且 fsync pending 高，说明刷盘跟不上写入，磁盘压力正在累积 - 定期跑
SELECT FILE_NAME, TABLESPACE_NAME, TOTAL_EXTENTS * EXTENT_SIZE FROM INFORMATION_SCHEMA.FILES WHERE FILE_TYPE = 'DATAFILE'，比对TOTAL_EXTENTS的月环比增幅
空间规划最难的不是算数字，而是把应用写入节奏、MySQL 内部机制、OS 层 I/O 调度这三层耦合关系理清楚。漏掉任何一层，预估都会差一个数量级。
