MVCC 生命周期：建完不是终点

沿用第 1 章的 doc_chunks 表。一个常见且无害的操作，是给某段 chunk 换一版 embedding（换了 embedding 模型，或文档被重新切分）：

-- 看似只是"改一列"，MVCC 下却是删旧行 + 插新行
UPDATE doc_chunks
SET    embedding = $new_vec
WHERE  id = 12345;

-- 删除一个租户的全部文档：每行留下一个死元组，等 vacuum
DELETE FROM doc_chunks WHERE tenant_id = 42;

这两条 SQL 在堆表里留下的"尸体"，正是这一章的主角。它们怎么影响那张已经建好的 HNSW 图，决定了几天后同一条检索查询还准不准。

3.1写入之后，图不动

UPDATE/DELETE 不会从 HNSW 图里摘掉对应节点——节点仍指着已死的堆行，靠 scan 时的可见性判定事后把它筛掉。

底层机制（比文档深一层）：在 MVCC 里，一次 UPDATE 是删旧元组 + 插新元组，一次 DELETE 只是给旧元组打上死亡标记（事务结束后对新快照不可见）。无论哪种，旧的堆元组在 VACUUM 真正回收它之前都物理留在堆页里。HNSW 这边：图里那个老节点的元组保存着一个 heaptids[] 数组（源码常量 HNSW_HEAPTIDS = 10，单个 element 元组最多挂 10 个堆 TID），数组里那个指向老行的 TID 原封不动——节点没被摘掉，边也没断。

那查询为什么没被这些"幽灵节点"污染？因为过滤发生在扫描时，而不是写入时：

• 检索时，HNSW 沿图游走，收集候选节点，把每个候选的堆 TID（xs_heaptid）逐个吐给执行器；
• 执行器拿 TID 去堆表取行并做 MVCC 可见性判定——已删除 / 当前快照不可见的，直接丢弃；
• 于是"老行还在图里"不影响正确性：死行会在可见性这一关被筛掉。图节点不在 UPDATE/DELETE 时删除，只是 scan 时被过滤。

3.2vacuum 三趟修图

HNSW 的 vacuum 不是通用索引清理，而是定制的三趟例程：剥死 TID → 重连邻居 → 标删清零；第二趟逐节点重算邻居，是全程最贵的一步。

底层机制（比文档深一层）：pgvector 为 HNSW 实现了专门的 hnswbulkdelete，源码里清清楚楚分三趟（Pass 1 / Pass 2 / Pass 3），不是 Postgres 的通用索引 vacuum：

• Pass 1 · 剥死 TID（RemoveHeapTids）：遍历 element 元组，把 heaptids[] 里指向死堆行的 TID 剔除。轻量，主要是改数组、置无效标记。
• Pass 2 · 重连邻居（RepairGraph，最贵的一趟）：对每个"曾把某个被删 element 当邻居"的节点，调用 HnswFindElementNeighbors() 重新计算替补边并覆写邻居元组，把因删节点而断掉的连通性补回来。这一步逐节点重跑邻居搜索，是全程的写放大与耗时来源。
• Pass 3 · 标删 + 清零（MarkDeleted）：把已无有效 TID 的 element 标记为 deleted 并清零其向量数据，页空间留待复用。

三趟之间靠两把页级锁串行：HNSW_UPDATE_LOCK 把 vacuum 的重连和并发插入隔开，HNSW_SCAN_LOCK 把它和并发扫描隔开——保证正在跑的检索永远不会游走到一个"修了一半"的节点上（读邻居时还会校验 element 版本，防止读到已被替换的旧节点）。

3.3churn → 召回腐烂 → REINDEX

高 churn 表上召回会按天/周腐烂；vacuum 只修补不重排，死元组比例到 10–15% 时，REINDEX CONCURRENTLY 重建一张干净图，比死等 vacuum 划算。

底层机制（比文档深一层）：召回腐烂有两条叠加的路径，都能追回前两节——

• 死节点占着候选预算（§3.1）：vacuum 没跟上时，搜索游走仍会路过大量死节点，它们挤进 ef_search 候选池、又被可见性筛掉，等效于缩小了有效搜索宽度，召回向下掉（病态情况趋近 0%）。
• 绕行边累积（§3.2）：vacuum 跟上了，但它只修补不重排，反复删插让图攒下越来越多绕道，平均跳数变长、近邻越来越容易被错过——召回即使 vacuum 健康也仍在缓降。

所以运维上有两个动作，对应两条路径：

-- 1) 高 churn 表：把 autovacuum 调激进，别等默认 20% 死元组才触发
ALTER TABLE doc_chunks SET (
    autovacuum_vacuum_scale_factor = 0.05,   -- 5% 死元组就 vacuum
    autovacuum_vacuum_cost_delay   = 0
);

-- 2) 看死元组比例：n_dead_tup / (n_live_tup + n_dead_tup)
SELECT relname, n_live_tup, n_dead_tup,
       round(100 * n_dead_tup / nullif(n_live_tup + n_dead_tup, 0), 1) AS dead_pct
FROM   pg_stat_user_tables
WHERE  relname = 'doc_chunks';

-- 3) 比例到 ~10–15%、或召回掉下来：重建干净图（不锁表）
REINDEX INDEX CONCURRENTLY doc_chunks_embedding_idx;