数据库容量规划的核心目标是什么？
不是追求最大存储，而是保障业务稳定、查询高效、扩容平滑。重点在于预估数据增长节奏、识别瓶颈点（磁盘、IOPS、连接数、内存）、预留合理冗余，并设计可落地的扩容路径。
如何估算未来 1 年的数据量？
从最小可计量单元入手：单条记录平均大小 × 每秒 / 每天新增记录数 × 时间周期。需分层计算：
- 行级估算 ：用
SELECT AVG(LENGTH(CONCAT(col1,col2,……))) FROM table LIMIT 10000或INFORMATION_SCHEMA.TABLES中的AVG_ROW_LENGTH辅助判断；注意 TEXT/BLOB 实际存储可能在行外 - 写入频率 ：查应用日志或监控（如 Prometheus + MySQL exporter），确认峰值 QPS 和日均写入量，区分主键插入、批量导入、更新占比
- 索引膨胀 ：二级索引越多、字段越宽（尤其字符串索引），索引体积可能超过数据本身；InnoDB 主键聚簇，二级索引含主键值，需一并计入
- 保留策略 ：归档机制是否开启？binlog、slow log、error log 的保留天数直接影响磁盘占用
哪些指标比“总容量”更关键？
单纯看磁盘剩余空间容易误判。真正影响可用性的硬约束包括：
- 可用 InnoDB 表空间碎片率 ：
SELECT (DATA_FREE / DATA_LENGTH) AS frag_ratio FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_SCHEMA='db' AND ENGINE='InnoDB'；长期高更新表碎片 > 25% 会显著拖慢写入 - redo log 循环写压力 ：观察
SHOW ENGINE INNODB STATUS中的Log sequence number和Log flushed up to差值，差值持续过大说明刷盘跟不上，可能触发强制 checkpoint 影响性能 - buffer pool 命中率 ：低于 95% 需关注——不是盲目加内存，而是先检查是否有未走索引的大范围扫描或低效查询把热数据挤出
- max_connections 实际使用率 ：连接数打满会导致新连接拒绝；注意应用连接池配置是否合理，避免短连接风暴
容量告警和扩容怎么设计才不被动？
靠人工巡检肯定来不及。应建立分级自动响应机制：
- 预警阈值分三级 ：磁盘使用率 75%（查增长趋势）、85%（触发归档检查）、90%（锁定 DDL+ 准备扩容）
- 扩容优先选水平拆分或读写分离 ：单实例垂直扩容（换更大机器）有上限且停机风险高；分库分表需提前在业务层埋点支持，不要等撑不住再改
- 测试扩容操作本身 ：比如 alter table 加索引，在从库上先跑通，确认锁类型（ALGORITHM=INPLACE）、耗时、对主从延迟的影响
- 留一条“逃生通道”：例如配置临时 binlog 过期为 1 小时，紧急时快速释放空间；但必须同步通知运维团队并限期恢复规范策略
