docs(memory): 记录蜜罐表体积实测数据与 PostgreSQL 死元组/VACUUM 语义

2026-10-21 13:17:06 +08:00
parent 63e851ddae
commit cbb0c51a14
2 changed files with 64 additions and 0 deletions
@@ -45,3 +45,17 @@
 - `RecordHoneypot` 的键必须与 `Record` 一致（同样 `shared.LimitKey` 归一化），否则 `IsBanned` 判不出来。
 - 备份/配置/密钥泄露扫描（`/backup.zip`、`/db.sql`、`/id_rsa.pem`）文件名主体随机，**只有后缀稳定**
  → 用 `path.Base()` 后缀匹配表，不能只靠子串（`"/.zip"` 匹配不到 `/backup.zip`）。
+
+### 蜜罐表体积与自动清理（2026-10-21）
+- `honeypot_hits` 是**只追加**审计表，写入完全由外部扫描流量驱动（不可预期、不可节流）
+  → 必须有自动保留期清理，否则表体积只增不减。
+- 两道闸：时间（`honeypot_retain_days`）+ 数量（`honeypot_max_rows`）。数量闸不可省 ——
+  攻击者可用海量源 IP 在保留期内把表撑爆。
+- ⚠️ PG 的 `DELETE` 只标记死元组，**表文件不会变小**；无 VACUUM 时表体积单调膨胀
+  （实测 22→52 MB）。清理后必须 `VACUUM (ANALYZE)`，但注意 **VACUUM 不缩小文件、
+  只让空间可复用**（止住增长即可，不必 `VACUUM FULL`）。
+- ⚠️ `VACUUM` 不能在事务块/函数体内执行 → GORM 走 `Exec()`（Raw 处理器，不包事务）可行。
+- ⚠️ 清理器的 `runOnce` 必须自己再挡一次 `retainDays<=0`，否则「保留 0 天」= 全删光。
+- 索引：GORM 去掉 struct tag 的 `index` **不会**删既有库上的旧索引 → 需显式 DropIndex。
+  删索引前先用 EXPLAIN 确认零查询使用（`provider` 索引实测 10 万行 648 kB 且零使用）。
+- CLI `honeypot size` 报告行数/磁盘占用/时间跨度 —— 把「有没有臃肿」交给运维自查。