影像存储容量测算：为什么“翻倍”会打爆磁盘
影像系统的磁盘告警，通常不是“用得太多”，而是“算得太少”。
一个常见场景：当前占用 70%，按年增长 30% 估算，看起来还能撑两年。实际三个月后就告警了。原因是估算时漏掉了三件东西。
漏项一：在线数据没有被清理
影像数据有生命周期。检查做完后一段时间内是热数据，之后转冷，再之后应该归档或删除。
但很多现场的实际状态是：归档脚本配了，没在跑；或者跑了，但只删了数据库记录，文件还留在磁盘上。
这类“孤儿文件”不会自己消失。检查方法很简单：比对数据库里的文件路径和磁盘上的实际文件。
# 统计实际文件数
find /data/pacs -type f | wc -l
-- 数据库里的记录数
SELECT COUNT(*) FROM study_file;两个数差得越多，说明清理策略越失效。
漏项二：副本和临时文件
算容量只看主存储是不够的。至少要把这些算进去：
- 数据库归档日志（增长快，且不能随便删）
- 数据库备份集（通常占主库的 1~2 倍）
- 上传网关的本地缓存（归档完成后才释放）
- 系统盘日志、临时表空间
一个实用的经验值：业务数据 1 TB，整套环境实际要按 2.5~3 TB 准备。
漏项三：单张检查的体积在变大
CT 从 16 排到 64 排、128 排，单次检查的层数和分辨率都在涨。同样的人次，产生的数据量可能翻几倍。
所以按“人次 × 历史均值”估算会持续偏低。正确做法是按设备分别统计近半年的平均检查体积，再看新设备的趋势。
一个可用的测算模型
不要追求精确到 GB，算清楚量级就够：
年增量 = 年检查人次 × 平均单次体积 × (1 + 年增长率)
实际需求 = 现有占用 + 年增量 × 保留年数 × 冗余系数其中：
- 平均单次体积：按设备类型分开取，CT/MR 远大于 DR、超声
- 保留年数：按院方要求，通常是 3 年在线 + 归档
- 冗余系数：1.2（快照、临时文件、索引）
什么时候该扩容，什么时候该治理
判断标准不是占用率，而是增长速率：
- 年增长 < 20%：先做治理，清理过期数据和孤儿文件
- 年增长 20%~50%：治理 + 按两年容量规划扩容
- 年增长 > 50%：必须拆存储池，同时复核保留策略是否合理
磁盘告警只是症状。真正的病是“数据只进不出”，扩容只能买到时间，买不到秩序。
顺手可以做的一件事
给存储加一条每日巡检，记录占用率和文件数。三个月后你就有真实的增长曲线，比任何估算都准。
-- 每天记一条，积累一个月就能看出斜率
INSERT INTO storage_daily (stat_date, total_gb, used_gb, file_count)
VALUES (TRUNC(SYSDATE), 8000, 6120, 4821337);