db-storage-bloat

db-storage-bloat (M18)

存储可运维性可让数据库长期保持快速且正常运行；这是 Performance & Scale（轴 performance）方面的关注点，为关系型 Almacenamiento w12（与 M22/M20/M21 共用）和宽列配置中的 Tombstones 类别提供信息。灾难性情况——TXID 回卷——可能迫使 Postgres 关闭，因此如果迫在眉睫， 其 severity:5 为上限。

检查内容

1. VACUUM / autovacuum 健康状况 — 高变更频率表上禁用了 autovacuum 或配置不当，死元组不断累积， 表/索引膨胀导致体积增大、扫描变慢。
2. TXID 回卷 — age(datfrozenxid)（或逐表的 relfrozenxid）接近 autovacuum_freeze_max_age / 20 亿上限。只有基于实时年龄证据，才能将回卷认定为迫在眉睫， 并标记为 severity:5、fail（perf）；静态检查最多只能提示 needs_api。
3. 墓碑（宽列） — Cassandra/Scylla 中大量删除 / TTL 变更会产生墓碑，进而降低读取性能（接近 tombstone_warn_threshold 的范围）。

评分 / 轴

仅为 performance 提供信息（关系型 Almacenamiento w12；宽列配置中的 Tombstones）。

Tier-0（静态）

M18 几乎所有检查都依赖运行时真实数据。静态检查可检测禁用 autovacuum 的 DDL/配置 （autovacuum_enabled = false、激进的 fillfactor）、高删除率/TTL 访问模式，以及 宽列中以大量删除为主的数据建模。死元组数、实际膨胀程度、冻结 xid 年龄和墓碑数都需要连接实时数据库 才能获取 → Tier-0 状态为 needs_api（绝不静默判定通过）。

Tier-1/2（Postgres 验证查询）

-- TXID wraparound headroom (Tier-1):
SELECT datname, age(datfrozenxid) AS xid_age,
       current_setting('autovacuum_freeze_max_age')::int AS freeze_max
FROM pg_database ORDER BY age(datfrozenxid) DESC;
-- dead tuples + last autovacuum (Tier-2):
SELECT relname, n_dead_tup, n_live_tup, last_autovacuum
FROM pg_stat_user_tables ORDER BY n_dead_tup DESC LIMIT 20;

方法 query_stat。xid_age 接近 freeze_max（或 2e9 上限）时，可确认回卷已 established，并触发上限。n_dead_tup 较高且 last_autovacuum 过期或为 NULL 时，可确认膨胀已 established；如果缺少持续统计数据，膨胀仍为 directional。

发现项

按 schema/finding.schema.json 输出发现项。示例：

• M18.db.txid_wraparound_imminent — xid_age 接近上限（severity:5、fail、轴为 performance，置信度为 established 仅限 Tier-1 / Tier-0 为 needs_api，fixable: advisory — 积极执行 VACUUM (FREEZE)）。
• M18.events.autovacuum_disabled — 高变更频率表上关闭了 autovacuum（severity:3、warn， 来自 DDL 的状态为 established，fixable: proposed）。
• M18.events.dead_tuple_bloat — 死元组比例较高（severity:3、warn，Tier-2 为 established / needs_api，fixable: advisory）。

每个发现项：evidence.observed 原样引用配置/DDL 行或目录/统计信息行；verification.reproduce 是上方 引用 $DATABASE_URL 的查询；expected_impact 需标明区间和置信度（不得只给出百分比）。

诚信原则

• severity:5 的回卷判断必须有实时 age() 证据——绝不能仅凭文件就宣称回卷迫在眉睫；没有连接时， 应输出 needs_api，这不会触发上限。
• 一定程度的“膨胀”是正常的稳态余量；只有结合变更模式或测得的死元组比例时才标记，并将仅基于文件的 判定标为 directional。
• 不得引用无法观测到的死元组百分比或回卷剩余天数；只能标注幅度区间。常规维护修复（VACUUM、 autovacuum 调优）标记为 proposed/advisory。

解决方案 — 让更新保持 HOT

对于更新频繁的表，降低 FILLFACTOR（例如将默认值 100/90 降至 70），可在每个页面中留出空闲空间， 让 UPDATE 将新行版本放在与原行相同的页面上，从而实现 HOT（仅堆元组） 更新——此操作跳过写入新的索引项，减少索引写入放大并减缓膨胀增长。只有在未更改任何索引列且页面有空间时， HOT 才会生效，因此降低 FILLFACTOR 并避免对变更频繁的列建立过多索引，才是有效手段。这是对上述 autovacuum/膨胀发现项的积极应对；将其标记为 fixable: proposed（修改 FILLFACTOR 只会在后续更新时重写）。