数据库容量告警关键在分层观测、周期校准与余量管理：表级增长、索引膨胀、临时段/undo log需分别监控；用滚动12周数据拟合斜率，R²＜0.85需人工干预；预测结果须绑定归档、锁DDL、扩容等动作。

数据库容量告警本身不解决根本问题，关键在于提前预判增长节奏、识别异常拐点、留出合理扩容窗口。一个实用的增长趋势预测模型，不需要复杂机器学习，核心是“分层观测 + 周期校准 + 容量余量管理”。

按对象粒度分层监控实际增长

只看总库大小容易掩盖风险。应拆解到三类关键对象分别建模：

• 表级增长：重点关注业务主表（如订单表、日志表）、历史归档表。用SELECT table_name, data_length + index_length FROM information_schema.tables定期采集，计算周/月增量；对无分区的大日志表，需单独统计每日INSERT量级与平均行大小，反推空间消耗。
• 索引膨胀：特别是频繁UPDATE的字段上存在冗余索引时，innodb_data_file_path和information_schema.innodb_sys_indexes可辅助识别低效索引导致的空间浪费。
• 临时段与undo log：长事务、大事务回滚、未及时purge的undo history会持续占空间。通过SHOW ENGINE INNODB STATUS中的HISTORY LIST长度判断undo积压程度。

用滚动周期拟合真实增长斜率

固定用线性回归拟合全年数据往往失真。建议采用动态滚动窗口法：

• 取最近12个自然周的磁盘占用快照（非备份大小，是df -h或sys.dm_os_volume_stats结果），剔除明显异常点（如某周因误删重建索引导致突降）；
• 对剩余数据做最小二乘拟合，得到当前周均增长量（KB/week）及R²值；若R²＜0.85，说明趋势不稳定，需人工检查是否引入新模块、流量激增或归档策略失效；
• 每两周自动重算一次参数，并对比前次斜率变化——连续两次斜率增幅＞40%，触发“潜在加速增长”二级预警。

把预测结果转化为可执行的容量动作

预测数字必须绑定明确运维动作，否则就是纸面告警：

• 当预测剩余可用天数＜30天：自动触发归档脚本（如将6个月前订单状态归档至冷库存储），并邮件通知DBA+业务方确认归档范围；
• 当预测剩余可用天数＜14天：锁定DDL权限，禁止新建索引或扩大字段长度，同时启动扩容评估流程（含存储IO压力验证）；
• 每次扩容后，重置基线时间点，并将本次扩容容量、生效时间、预估新耗尽时间写入元数据库db_capacity_plan表，供后续回溯比对。

模型效果不取决于算法多先进，而在于是否能和归档策略、发布节奏、监控链路真正咬合。上线后第一件事，是拿过去三个月的实际增长反推模型误差——如果平均偏差＞15%，优先检查采集频率是否覆盖了批量作业窗口，而不是升级模型。