容量预测需结合业务增长与数据生命周期，公式为预估容量=（日均新增行数×平均行大小×保留天数）×（1+碎片率+索引冗余），碎片率通常取5%~15%，索引应按高频查询精建联合索引，并定期清理未用索引；单表超2000万行或50gb时宜分区（如按时间或租户）与归档冷数据；磁盘须预留20%空间并设85%使用率等阈值告警。
容量预测要结合业务增长和数据生命周期
数据库容量不是静态值，得看业务数据量的年增长率、单条记录大小、写入频率，以及归档或删除策略。比如用户表每月新增10万条，每条约2KB，一年就是2.4GB；若保留5年历史且不做归档，光这一张表就占12GB以上。建议用公式粗估：预估容量 = （日均新增行数 × 平均行大小 × 保留天数）×（1 + 碎片率 + 索引冗余）。碎片率可参考pg_total_relation_size()（PostgreSQL）或sp_spaceused（SQL Server）的实际膨胀比例，通常设5%~15%较稳妥。
索引不是越多越好，而是按查询模式精建
高频WHERE、JOIN、ORDER BY字段才值得建索引；全表扫描比维护冗余索引更省资源。例如订单表常按user_id + status + created_at组合查询，建联合索引(user_id, status, created_at)比三个单列索引高效得多——它能覆盖查询条件+排序，避免回表。但若只查created_at，该联合索引可能不生效，需单独补一个。定期用EXPLAIN分析慢查询，删掉3个月未被使用的索引（可通过pg_stat_all_indexes或SQL Server的DMV视图确认）。
分区和归档是控制物理容量的关键手段
单表超2000万行或体积超50GB时，性能易下滑。按时间（如按月分区）或业务维度（如按区域、租户ID）切分，既加快查询（优化器可剪枝），也方便清理旧数据。例如日志表按log_date范围分区后，删3个月前数据只需DROP PARTITION，远快于DELETE。归档则把冷数据迁出主库——可用物化视图同步热数据，或用ETL任务定期导出压缩文件并标记为已归档，主表仅保留最近6个月。
预留空间与监控必须常态化
磁盘空间至少预留20%，避免自动扩展失败导致写入阻塞；表空间/文件组也要留余量，防止因autoextend配置不当引发IO争用。设置阈值告警：当数据库使用率达85%、单表行数突破预设上限、或索引数量超30个时触发通知。工具上，Prometheus+Grafana配pg_stat_database指标，或SQL Server Agent作业跑自定义脚本，都能低成本实现闭环监控。
