容量预测需结合业务增长与数据生命周期，公式为预估容量 =（日均新增行数×平均行大小×保留天数）×（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 作业跑自定义脚本，都能低成本实现闭环监控。
