数据库容量预估需量化推演：先锁定高增长表，明确初始存量、日均增量、保留周期；再计算单行体积（含行头、NULL标记、VARCHAR前缀等）和索引开销；分阶段建模并预留30%–50%弹性，每月校准偏差＞15%时更新模型，标注时间节点支撑扩容决策。
数据库容量预估不是靠拍脑袋，而是结合业务逻辑、数据增长规律和存储结构做量化推演。核心是把“未来要存多少条记录”“每条占多大空间”“索引和冗余带来多少额外开销”三块算清楚。
从核心业务实体出发，拆解数据增长主干
先锁定系统里最“吃空间”的几张表，比如订单表、日志表、用户行为流水表。这些通常是容量增长的主力。对每张表，明确三个变量：
- 初始存量：上线时已有的记录数（如历史订单100万条）
- 日均增量：按真实业务节奏估算（如电商大促期订单日增50万，平日8万）
- 保留周期：数据是否归档或删除（如订单只保留3年，日志保留90天）
例如：订单表当前120万条，日均新增25万，保留36个月。粗略估算：25万 × 30 × 12 × 3 ≈ 2700万条，加上存量约2820万条——这是行数基准。
单行体积不能只看字段定义，要算实际存储开销
INT不是固定4字节，VARCHAR不是“长度×字符集字节数”那么简单。要考虑：
- 行头开销（MySQL InnoDB约23–29字节/行，含事务ID、回滚指针等）
- NULL值不占存储但需1位标记位（多个NULL共用字节）
- VARCHAR真实占用 = 实际字符串长度 + 1或2字节长度前缀（取决于最大长度）
- 索引单独计算：主键B+树每页约15KB，非唯一二级索引还包含主键值，会放大存储
建议用SHOW TABLE STATUS查Avg_row_length作为起点，再结合SELECT AVG(LENGTH(CONCAT(...))) FROM 表 LIMIT 10000采样验证。
按业务阶段分段建模，避免线性外推失真
用户量翻倍，订单量未必翻倍；新功能上线可能引发某类日志激增10倍。需识别关键拐点：
- 冷启动期（0–6个月）：增长缓慢，以种子用户行为为主，按周粒度估算
- 爬升期（6–18个月）：渠道放量、活动密集，按日均+峰值系数（如大促日×3.5）建模
- 稳定期（18个月+）：关注留存率与复购率变化，引入衰减因子（如月活用户年衰减15%）
例如：用户行为日志表在接入埋点SDK后，单UV日均事件从30条跳到220条，这个跃变必须在模型中显式标注，否则容量会低估3倍以上。
预留弹性并持续校准，把预估变成闭环动作
首次预估建议上浮30%–50%应对未知膨胀（如TEXT字段误存长JSON、索引未及时优化）。更重要的是建立校准机制：
- 每月比对data_length + index_length实际增长 vs 模型预测值
- 当偏差＞15%时，回溯原因：是字段变更？还是业务规则调整？更新模型参数
- 把容量告警（如磁盘使用率＞75%）和DDL变更（如加索引、改字段类型）联动，形成反馈闭环
不复杂但容易忽略：很多团队只算“现在要多少”，却没定“什么时候要”。务必在预估结果中标注时间节点（如“2025年Q3末预计达1.2TB”），让扩容决策有据可依。
