数据库容量规划的核心目标是什么？
不是追求最大存储，而是保障业务稳定、查询高效、扩容平滑。重点在于预估数据增长节奏、识别瓶颈点（磁盘、IOPS、连接数、内存）、预留合理冗余，并设计可落地的扩容路径。
如何估算未来 1 年的数据量？
从最小可计量单元入手：单条记录平均大小 × 每秒/每天新增记录数 × 时间周期。需分层计算：
iWebShop开源商城系统
下载
iWebShop是一款基于PHP语言及MYSQL数据库开发的B2B2C多用户开源免费的商城系统，系统支持自营和多商家入驻、集成微信商城、手机商城、移动端APP商城、三级分销、视频电商直播、微信小程序等于一体，它可以承载大数据量且性能优良，还可以跨平台，界面美观功能丰富是电商建站首选源码。iWebShop开源商城系统 v5.14 更新日志：新增商品编辑页面规格图片上传优化商品详情页面规格图片与主图切
-
行级估算：用
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 小时，紧急时快速释放空间；但必须同步通知运维团队并限期恢复规范策略
