PostgreSQL（关系型数据库）存储、MVCC（多版本并发控制）、索引与查询路径

本篇建立关系型交易工作负载的存储、事务、读写、查询和维护基准。项目版本统一登记为“待现场核对”；跨版本稳定机制可以直接学习，版本敏感行为必须在目标环境中对照官方手册与最小实验复核。文中数据均为教学演绎，不代表生产现状。

1. 版本与学习边界

1.1 cluster（集群实例）到物理文件的对象层级

PostgreSQL（关系型数据库）的 cluster（集群实例）是一个服务进程组管理的数据目录，不等于分布式集群；一个 cluster（集群实例）包含多个 database（数据库），database（数据库）之间不能直接用普通名称解析对象。database（数据库）内部以 schema（模式）组织命名空间，schema（模式）中的 table（表）、index（索引）、sequence（序列）等都属于 relation（关系）。relation（关系）落盘后按 fork（分支文件）区分主数据、FSM（空闲空间映射）、VM（可见性映射）和初始化分支，并在文件达到阈值后拆成 segment（文件段）；segment（文件段）再由固定大小的 page（页）组成，heap（堆表）的 page（页）保存 tuple（元组）。

flowchart LR
    C["cluster 集群实例"] --> D1["database 业务库"]
    C --> D2["database 运维库"]
    D1 --> S["schema 模式"]
    S --> R["relation 关系"]
    R --> F1["主数据分支"]
    R --> F2["空闲空间映射分支"]
    R --> F3["可见性映射分支"]
    F1 --> G["segment 文件段"] --> P["page 页"] --> T["tuple 元组"]

图解：节点从服务管理边界逐层下钻到行版本，箭头表示包含或物理映射。前提是对象已创建并分配存储；正常路径由名称解析定位 relation（关系），再由文件块号定位 page（页）；失败路径包括连接错 database（数据库）、搜索路径命中同名对象和把文件段误判成分片；业务结论是容量、权限与故障定位必须先说清层级，不能用“某张表很大”替代物理证据。

数据演绎 1：层级与文件段。 假设一张 WMS（仓储管理系统）库存流水 heap（堆表）为 2.4 GiB（吉字节），主数据 fork（分支文件）可能拆成多个 segment（文件段），同时还存在索引 relation（关系）、FSM（空闲空间映射）与 VM（可见性映射）。看到四个大文件不能推导存在四份业务表；应先由对象标识映射 relation（关系），再汇总其全部 fork（分支文件）与索引。

热门面试题

1. 问题（基础题）：请从 cluster（集群实例）讲到 tuple（元组）。
   • 考点：逻辑对象与物理对象的映射。
   • 回答思路：按服务、命名空间、关系、文件和页逐层说明。
   • 详细答案：cluster（集群实例）管理多个 database（数据库），database（数据库）内由 schema（模式）组织 relation（关系）；relation（关系）按 fork（分支文件）分工，文件过大后拆成 segment（文件段），segment（文件段）由 page（页）组成，heap（堆表）页保存 tuple（元组）版本。索引也是独立 relation（关系），不是 heap（堆表）文件内部的一段。
   • 进阶追问：为什么不能用文件数推断表数？
   • 进阶回答：一张表可能有多个 fork（分支文件）、segment（文件段）和索引 relation（关系），还可能关联 TOAST（超大字段存储）对象。
2. 问题（原理题）：schema（模式）解决什么问题？
   • 考点：名称隔离与权限边界。
   • 回答思路：区分逻辑命名空间和物理存储。
   • 详细答案：schema（模式）为同一 database（数据库）中的对象提供命名与权限边界，名称解析受搜索路径影响；它不承诺对象按独立目录存放，也不形成跨 database（数据库）事务边界。排障时必须记录全限定名，避免同名对象导致计划和数据来源误判。
   • 进阶追问：连接到错误 database（数据库）会怎样？
   • 进阶回答：即使 schema（模式）与表名相同，也会访问另一套系统目录和 relation（关系），普通查询不能跨库解析目标对象。
3. 问题（场景题）：磁盘告警时如何判断是哪张表增长？
   • 考点：relation（关系）及其附属对象归因。
   • 回答思路：从对象大小、索引、TOAST（超大字段存储）和时间增量交叉。
   • 详细答案：先按 relation（关系）汇总 heap（堆表）、索引与 TOAST（超大字段存储）的逻辑大小，再映射主数据、FSM（空闲空间映射）和 VM（可见性映射）文件，比较同时间窗增量。仅看数据目录文件名会遗漏附属对象，也无法区分新数据、膨胀和索引增长。
   • 进阶追问：第一轮能直接删文件吗？
   • 进阶回答：不能，关系文件受存储管理器和日志恢复约束，应先止住异常写入并通过受支持的维护动作处理。

1.2 page（页）、tuple（元组）、FSM（空闲空间映射）、VM（可见性映射）与 TOAST（超大字段存储）

heap（堆表）page（页）包含页头、行指针数组、从页尾向前增长的 tuple（元组）区和两者之间的空闲区。行指针让 tuple（元组）在页内移动时仍可由稳定槽位引用。tuple（元组）头保存 xmin、xmax、标志位和空值等元数据；FSM（空闲空间映射）近似记录哪些 page（页）有可用空间，帮助插入避免全表搜索；VM（可见性映射）记录 page（页）是否对所有事务可见以及是否已冻结，服务仅索引扫描和清理跳页。TOAST（超大字段存储）会先尝试压缩，再把过大的变长值拆片放入独立 relation（关系），主 tuple（元组）保留指针。

flowchart TD
    H["page 页头"] --> L["行指针数组"]
    L --> F["中间空闲区"]
    F --> T["tuple 元组区"]
    I["插入器"] --> M["空闲空间映射"] --> F
    Q["仅索引扫描"] --> V["可见性映射"] --> T
    T -->|"大字段指针"| O["超大字段存储关系"]

图解：页内节点展示头部、槽位、空闲区和行版本，侧边节点表示 FSM（空闲空间映射）、VM（可见性映射）和 TOAST（超大字段存储）的辅助关系；箭头表示选页、可见性捷径与大值外置。前提是 page（页）未损坏且映射可用；正常路径避免盲扫和回表可见性检查；失败路径是映射失效、宽行频繁读取或页空间碎片化；业务结论是“命中索引”不代表只读一个文件，行宽和可见性同样决定延迟。

数据演绎 2：8 KiB（千字节）页面。 教学假设 page（页）大小为 8 KiB（千字节），扣除页头 24 B（字节）后，若每个行指针 4 B（字节）、每个 tuple（元组）连同头部和对齐平均 180 B（字节），理论上约容纳 floor((8192-24)/(4+180))=44 行；真实值还受空值位图、对齐、填充因子与大字段影响。若一列 20 KiB（千字节）文本被 TOAST（超大字段存储）外置，列表查询不访问该列可保持主行较窄，详情查询则要额外读取拆片。

热门面试题

1. 问题（基础题）：FSM（空闲空间映射）与 VM（可见性映射）有什么区别？
   • 考点：空间选址和可见性捷径。
   • 回答思路：分别回答谁写、谁读、失效后影响什么。
   • 详细答案：FSM（空闲空间映射）记录 page（页）大致可用空间，帮助插入和更新寻找容身位置；VM（可见性映射）记录 page（页）是否全可见或全冻结，帮助仅索引扫描减少 heap（堆表）访问，也让清理跳过部分 page（页）。两者都是辅助信息，不替代 heap（堆表）本身。
   • 进阶追问：VM（可见性映射）标记为什么会被清除？
   • 进阶回答：page（页）出现可能影响全可见结论的新版本或删除标记后，必须清除捷径，等待后续清理重新确认。
2. 问题（原理题）：为什么需要行指针？
   • 考点：页内槽位和 tuple（元组）移动。
   • 回答思路：说明稳定引用与空间整理的矛盾。
   • 详细答案：索引项通常定位 heap（堆表）的块号与槽位，行指针提供稳定槽位；即使 tuple（元组）在页内整理时移动，槽位仍可指向新位置。这样空间管理不必让所有外部引用随页内移动而重写，但跨页产生新版本时仍可能新增索引项。
   • 进阶追问：行指针能跨 page（页）保持不变吗？
   • 进阶回答：不能把页内稳定性外推到跨页更新，跨页版本需要新的物理位置和相应索引处理。
3. 问题（场景题）：大字段表为何列表快而详情慢？
   • 考点：TOAST（超大字段存储）延迟读取。
   • 回答思路：从投影列、压缩、拆片和随机读取解释。
   • 详细答案：列表若只取窄列，可只访问主 tuple（元组）和必要索引；详情读取被 TOAST（超大字段存储）压缩或拆片的大值时，需要额外访问附属 relation（关系）、重组并可能解压。应以实际投影列和缓冲命中验证，不能只按返回行数判断成本。
   • 进阶追问：把大字段移到业务子表一定更快吗？
   • 进阶回答：不一定，还要比较访问频率、连接成本、更新模式和 TOAST（超大字段存储）现有收益。

1.3 写路径、提交确认与三种完成时点

请求进入后端进程后依次经过 parse（解析）、rewrite（重写）、plan（计划）和 execute（执行）。执行器在 shared buffers（共享缓冲区）中读取或修改 page（页），把对应 WAL（预写日志）记录写入 WAL buffer（预写日志缓冲区），并为日志位置分配 LSN（日志序列号）。提交时，默认持久化语义要求提交记录对应的 WAL（预写日志）经 group commit（组提交）聚合后越过 fsync（强制刷盘）边界；脏数据页可以稍后由后台写入或 checkpoint（检查点）落盘。副本只有接收、写入、刷新或重放到相应 LSN（日志序列号）后，才分别达到不同阶段，不能与主库提交混为一谈。

sequenceDiagram
    participant C as 客户端
    participant B as 后端进程
    participant S as 共享缓冲区
    participant W as 预写日志缓冲区
    participant D as 预写日志文件
    participant R as 副本
    C->>B: 提交写请求
    B->>B: 解析 重写 计划 执行
    B->>S: 修改数据页并标脏
    B->>W: 追加日志与日志序列号
    W->>D: 组提交并强制刷盘
    D-->>B: 提交记录已持久化
    B-->>C: 提交成功
    D-->>R: 发送日志
    R->>R: 接收 写入 刷新 重放

图解：节点区分请求处理、内存数据页、日志缓冲、持久日志与副本，箭头表示语句处理和日志先行顺序。前提是持久化配置、存储语义与副本模式已现场确认；正常路径先让 WAL（预写日志）持久化再确认；失败路径包括 fsync（强制刷盘）慢、提交结果未知和副本重放落后；业务结论是支付或库存只能把主库提交当本地权威完成，读副本和异构投影必须另设可见水位。

数据演绎 3：group commit（组提交）。 假设单次 fsync（强制刷盘）耗时 4 ms（毫秒），20 个并发事务在同一刷新窗口提交。若逐事务串行刷盘，尾部理论等待可接近 80 ms（毫秒）；group commit（组提交）让多条提交记录共享一次或少数几次刷新，吞吐提高但单事务仍需等待对应 WAL（预写日志）越过持久化位置。响应丢失时，客户端不能仅凭超时重做资金动作，应按业务幂等键查本地事务结果。

热门面试题

1. 问题（基础题）：提交成功是否等于数据页已经刷盘？
   • 考点：WAL（预写日志）先行与提交语义。
   • 回答思路：分开日志持久化、脏页刷盘和副本可见。
   • 详细答案：默认持久化语义下，提交确认重点是提交记录对应的 WAL（预写日志）达到配置要求；heap（堆表）和索引脏页可以仍在 shared buffers（共享缓冲区），以后由后台写入或 checkpoint（检查点）刷盘。崩溃后依靠日志重放恢复这些尚未落盘的变化。
   • 进阶追问：为什么不要求每次提交刷所有数据页？
   • 进阶回答：随机刷多个数据页会显著放大延迟，WAL（预写日志）用顺序日志建立可恢复承诺，再异步组织数据页写入。
2. 问题（原理题）：LSN（日志序列号）有什么用？
   • 考点：日志顺序与恢复水位。
   • 回答思路：串联页面、主库、副本和备份位置。
   • 详细答案：LSN（日志序列号）标识 WAL（预写日志）中的位置，可比较日志生成、刷新、传输与重放进度，也让 page（页）知道某次变化是否已被恢复处理。排查复制延迟或恢复缺口时，应比较位置差和时间差，而不是只看“连接正常”。
   • 进阶追问：位置差能直接换算成秒吗？
   • 进阶回答：不能，生成速率和重放能力随负载变化，需同时观察字节差、时间戳和当前吞吐。
3. 问题（场景题）：支付提交超时后能否直接重试？
   • 考点：未知结果和业务幂等。
   • 回答思路：先区分数据库回滚、已提交但响应丢失和连接中断。
   • 详细答案：不能把超时等同失败。应用应使用支付幂等键查询权威流水：若已提交则返回既有结果，若明确未发生才重新执行，若状态仍未知则进入查单或对账。数据库事务解决本地原子性，不能替代调用链的结果确认与外部副作用治理。
   • 进阶追问：读副本查不到能否判定未提交？
   • 进阶回答：不能，副本可能尚未重放目标 LSN（日志序列号），未知结果必须回权威写节点或使用确认水位。

1.4 WAL（预写日志）、full-page write（整页写）、checkpoint（检查点）与崩溃恢复

WAL（预写日志）的核心不变量是描述 page（页）变化的日志必须先于对应脏页持久化。checkpoint（检查点）记录恢复起点并推动此前脏页落盘；后台写入可提前平滑刷页，减少 checkpoint（检查点）末端压力。page（页）在 checkpoint（检查点）后首次被修改时，full-page write（整页写）可记录整页镜像，以防存储只写入部分 page（页）造成撕裂。崩溃恢复从检查点后的 WAL（预写日志）开始重放，未提交事务的影响不会按可见提交留下。频繁检查点会增加 full-page write（整页写）与刷盘压力，过稀则增加恢复时间和日志保留量。

sequenceDiagram
    participant B as 后端进程
    participant W as 预写日志
    participant P as 脏数据页
    participant C as 检查点
    participant X as 恢复进程
    C->>C: 记录检查点起始位置
    B->>W: 首次改页记录整页镜像
    B->>P: 修改内存页
    W-->>B: 日志先持久化
    C->>P: 分批刷出脏页
    P--xP: 崩溃时部分页未落盘
    X->>W: 从检查点后读取日志
    W-->>X: 日志记录与整页镜像
    X->>P: 重放并恢复一致页

图解：节点表示写入者、日志、脏页、检查点和恢复者，箭头强调日志先行、刷页与重放。前提是 WAL（预写日志）介质可读且 checkpoint（检查点）记录有效；正常路径由后台分散刷页，崩溃后从已知位置重放；失败路径是日志损坏、存储持久化语义不符或检查点尖峰拖慢前台；业务结论是恢复能力依赖完整日志链和演练，不能靠“数据文件看起来还在”判断安全。

flowchart LR
    T["事务提交"] --> G["日志生成速率"]
    G --> C{"检查点节奏"}
    C -->|"过密"| F["整页写与刷盘尖峰"]
    C -->|"适中"| B["后台平滑写入"]
    C -->|"过疏"| R["恢复时间与日志保留增加"]
    F --> O["观察前台延迟与磁盘"]
    B --> O
    R --> O

图解：节点把事务生成速率、检查点节奏和三类结果关联起来，箭头表示因果影响而非固定阈值。前提是负载窗口可比较；正常路径让后台写入与存储能力匹配；失败路径分为过密导致写尖峰和过疏导致恢复、空间压力；业务结论是参数调整必须同时满足前台延迟、恢复目标与磁盘水位，不能只优化单一指标。

数据演绎 4：检查点尖峰。 假设高峰 10 分钟产生 60 GiB（吉字节）脏页与 WAL（预写日志），存储持续写能力 150 MiB/s（兆字节每秒）。若大部分脏页集中在最后 90 秒刷出，仅数据页平均就需约 683 MiB/s（兆字节每秒），必然与前台日志刷新争用；若后台在 600 秒内较均匀刷出，平均约 102 MiB/s（兆字节每秒）。实际还要叠加索引、整页镜像、归档和其他进程，故需以磁盘延迟和检查点日志双证据验证。

热门面试题

1. 问题（基础题）：checkpoint（检查点）为什么不能越频繁越好？
   • 考点：恢复时间与写放大的平衡。
   • 回答思路：同时说明 full-page write（整页写）、刷脏页和恢复起点。
   • 详细答案：更频繁的 checkpoint（检查点）能缩短部分恢复范围，却会更频繁触发 page（页）在新周期内的首次整页镜像，并推动脏页写出，增加日志与磁盘压力。合理节奏应让后台写入平滑，满足恢复目标且不制造周期性前台延迟尖峰。
   • 进阶追问：如何证明尖峰来自检查点？
   • 进阶回答：对齐检查点开始结束、写出页数与耗时，并用磁盘写延迟和前台事务延迟作为第二类证据。
2. 问题（原理题）：full-page write（整页写）防什么故障？
   • 考点：page（页）撕裂与恢复。
   • 回答思路：说明首次修改、整页镜像和日志重放。
   • 详细答案：若系统崩溃时一个 page（页）只部分写入，单靠增量日志可能无法在损坏基线之上正确重放。checkpoint（检查点）后首次修改记录整页镜像，可在恢复时先还原完整 page（页）再应用后续变化；具体开关与存储前提属于版本核对卡内容。
   • 进阶追问：它等于备份吗？
   • 进阶回答：不等于，它服务崩溃一致性，不能替代独立备份、日志归档和恢复演练。
3. 问题（场景题）：WAL（预写日志）突然暴涨如何定位？
   • 考点：生成、保留和消费三段证据。
   • 回答思路：先区分写入变多、整页镜像变多和日志无法回收。
   • 详细答案：第一类证据看事务量、记录类型、检查点与 full-page write（整页写）变化，第二类证据看归档、复制槽和副本消费水位。止血要针对来源：限制异常批量、恢复归档或处理停滞消费者；不能在未知保留责任时直接删除日志文件。
   • 进阶追问：删除旧日志为何危险？
   • 进阶回答：可能破坏崩溃恢复、归档连续性或副本追赶，使原本可恢复的故障变成必须重建。

1.5 MVCC（多版本并发控制）、xmin、xmax（事务标识）与 snapshot（快照）可见性

MVCC（多版本并发控制）让读者依据 snapshot（快照）选择 tuple（元组）版本，而不是让普通查询与写入互相串行。每个 tuple（元组）的 xmin 指向创建它的事务，xmax 在删除、更新或某些锁操作后记录相关事务；可见性还要结合事务提交状态、当前 snapshot（快照）的活动事务集合和边界判断，不能只比较两个数字。更新通常创建新 tuple（元组）并让旧版本指向失效事务，不是在原地覆盖业务行。锁解决当前并发修改冲突，MVCC（多版本并发控制）解决读者看到哪个已存在版本，二者职责不同。

sequenceDiagram
    participant A as 事务一百
    participant B as 事务一百二十
    participant H as 堆表
    participant C as 事务一百四十
    A->>H: 插入余额一百 创建版本一
    A-->>A: 提交
    B->>B: 建立旧快照
    C->>H: 更新余额为八十
    H->>H: 版本一记录失效事务
    H->>H: 创建版本二
    C-->>C: 提交
    B->>H: 按旧快照读取
    H-->>B: 返回版本一
    participant D as 新事务
    D->>H: 建立新快照并读取
    H-->>D: 返回版本二

图解：节点是四个事务与 heap（堆表），箭头表示插入、更新、提交和按快照读取。前提是各事务状态可查且隔离级别决定快照生命周期；正常路径让旧读者继续看到版本一、新读者看到版本二；失败路径是长事务长期持有旧 snapshot（快照）或应用误把旧读当数据回退；业务结论是查询结果必须连同节点、事务起点和隔离级别解释，读到旧值不等于提交丢失。

数据演绎 5：逐行事务编号。 初始事务 100 插入 stock=10，tuple（元组）为 xmin=100,xmax=0 并提交。事务 110 在 Repeatable Read（可重复读）下建立 snapshot（快照）；事务 120 把库存改为 7，旧 tuple（元组）变成 xmin=100,xmax=120，新 tuple（元组）是 xmin=120,xmax=0，随后提交。事务 110 再读仍看到 10；事务 130 在 Read Committed（读已提交）下新语句建立 snapshot（快照）看到 7。事务 140 尝试改成 6 后回滚，其新版本不可见，事务 150 删除当前行并提交；事务 160 新读看不到该业务行，但旧 tuple（元组）尚未因此立刻从文件消失。

热门面试题

1. 问题（基础题）：xmin 与 xmax 能否直接决定可见性？
   • 考点：事务状态、快照边界与 tuple（元组）头。
   • 回答思路：说明字段只是输入，不是完整算法。
   • 详细答案：不能。xmin 和 xmax 标识创建、删除、更新或锁相关事务，还必须查询事务是否提交、回滚或仍进行中，并结合 snapshot（快照）的活动事务集合和边界。某个编号更小不代表必然可见，回滚事务创建的版本就应被排除。
   • 进阶追问：xmax=0 是否永远表示当前版本？
   • 进阶回答：不能孤立下结论，还要看创建事务状态和 tuple（元组）标志；原始字段语义应以目标版本实验核对。
2. 问题（原理题）：为什么更新会产生新 tuple（元组）？
   • 考点：并发读与版本保留。
   • 回答思路：用旧快照仍需读旧值解释。
   • 详细答案：若更新原地覆盖，更新前建立的 snapshot（快照）就无法继续读取一致旧值。创建新 tuple（元组）并保留旧版本，使读者按自身 snapshot（快照）选版本，写者再通过锁防止冲突更新；代价是死 tuple（元组）、清理和可能的索引写放大。
   • 进阶追问：这是否意味着读永不阻塞？
   • 进阶回答：不意味着，普通可见性读通常不等写锁，但架构锁、显式锁、资源争用和冲突语义仍可能阻塞或失败。
3. 问题（场景题）：库存已提交却有会话读到旧值，先查什么？
   • 考点：快照、节点与复制水位。
   • 回答思路：区分主库旧快照、副本落后和应用缓存。
   • 详细答案：记录查询节点、事务开始时间、隔离级别和目标业务版本；若在主库长事务中，旧 snapshot（快照）可能合法返回旧值；若在副本，比较目标 LSN（日志序列号）与重放位置；再排查缓存。不能用一次新连接查询覆盖原会话现场。
   • 进阶追问：如何保证写后立即读？
   • 进阶回答：在权威节点同一事务或确认达到目标重放水位后读取，并明确该保证只覆盖数据库，不覆盖异构投影。

1.6 HOT（堆内更新）、死 tuple（元组）、VACUUM（空间回收）、freeze（冻结）与回卷风险

当更新不改变任何索引键且原 page（页）有足够空间时，HOT（堆内更新）可让新 tuple（元组）留在同一 page（页），索引仍指向版本链入口，减少索引更新。条件不满足时，新版本可能跨 page（页）并为每个相关索引新增条目。旧版本在任何活跃 snapshot（快照）都不再需要后才可由 VACUUM（空间回收）处理：它清理死 tuple（元组）和无效索引项、更新 FSM（空闲空间映射）与 VM（可见性映射），让空间可复用。freeze（冻结）把足够老且稳定可见的创建事务语义转换为不受事务标识回卷影响的形式。普通 VACUUM（空间回收）通常不缩小文件；需要重写关系的动作才可能把空间归还操作系统，并带来额外锁与空间风险。

sequenceDiagram
    participant U as 更新事务
    participant I as 索引
    participant H as 堆表页
    participant L as 长事务
    participant V as 空间回收
    L->>L: 持有旧快照
    U->>H: 更新非索引列
    alt 同页有空间
        H->>H: 建立堆内版本链
        I-->>I: 保留原索引入口
    else 同页无空间或索引键变化
        H->>H: 跨页创建新版本
        U->>I: 写入新索引项
    end
    V->>L: 检查全局可回收边界
    L-->>V: 旧版本仍可能可见
    V--xH: 暂缓回收相关版本
    L-->>L: 事务结束
    V->>H: 清理并标记空间可复用

图解：节点覆盖更新、索引、heap（堆表）、长事务和清理者，箭头展示 HOT（堆内更新）成功、失败与回收门槛。前提是索引定义和页空间已知；正常路径在同页串联版本并在旧 snapshot（快照）结束后回收；失败路径是索引键变化、页满或长事务阻塞；业务结论是高更新表要同时治理行宽、填充空间、索引数量和事务时长，单调高 autovacuum（自动清理）频率不能修复所有膨胀。

数据演绎 6：HOT（堆内更新）命中与失败。 一张 Runner（执行器）任务表有 100 万行、5 个二级索引，每分钟更新 10 万次 heartbeat_at。若该列未被索引、page（页）预留空间足够，80% 更新命中 HOT（堆内更新），只有 2 万次需要普通新版本路径；若新增 heartbeat_at 索引或 page（页）长期接近满载，命中率降为 5%，约 9.5 万次更新要同时维护 5 个索引，索引项写入量从约 10 万级跃升到约 47.5 万级，还会增加后续清理工作。

数据演绎 7：长事务阻塞回收。 事务 200 在 09:00 建立 snapshot（快照）后保持 3 小时；期间每分钟更新 20 万行，平均旧 tuple（元组）200 B（字节），仅旧版本理论累计约 200000*180*200=7.2 GB（吉字节），尚未包含索引项和对齐。autovacuum（自动清理）即使持续运行，也不能回收该 snapshot（快照）仍可能访问的版本。第一证据是最老事务年龄和阻塞边界，第二证据是死 tuple（元组）、表与索引大小增长。

热门面试题

1. 问题（基础题）：HOT（堆内更新）成立需要什么条件？
   • 考点：索引键、同页空间与版本链。
   • 回答思路：说明“不改索引列”仍不充分。
   • 详细答案：更新不能改变任何相关索引键，新 tuple（元组）还要能放在原 page（页）。满足时索引可继续指向链入口，heap（堆表）在页内找到可见版本；若页满或表达式、部分索引条件受更新影响，就可能退化为普通更新。
   • 进阶追问：如何提高命中而不盲调参数？
   • 进阶回答：先识别高频更新列和实际索引依赖，再评估预留页空间、行宽与批量模式，用命中率和写入量验证。
2. 问题（原理题）：VACUUM（空间回收）为什么通常不让文件变小？
   • 考点：内部复用与归还操作系统。
   • 回答思路：拆分不可见、可复用和缩文件三个阶段。
   • 详细答案：删除提交只改变可见性；VACUUM（空间回收）在旧 snapshot（快照）不再需要后，把死 tuple（元组）和索引项清理为 relation（关系）内部可复用空间。文件中间的空洞仍属于该 relation（关系），普通清理通常不会整体重写并归还操作系统。
   • 进阶追问：何时考虑关系重写？
   • 进阶回答：持续无复用价值、磁盘确需回收且维护窗口允许时，评估锁、临时空间、WAL（预写日志）、副本和回滚风险后执行。
3. 问题（场景题）：事务标识回卷风险如何处理？
   • 考点：freeze（冻结）、年龄与阻塞者。
   • 回答思路：先保护推进清理的能力，再谈参数。
   • 详细答案：观察数据库、表和最老事务年龄，确认 autovacuum（自动清理）是否因长事务、锁、资源或配置落后；先结束不必要长事务、给冻结清理资源并保留磁盘余量，再按现场版本核对阈值。不能通过关闭保护机制换取短期可用。
   • 进阶追问：为什么长事务特别危险？
   • 进阶回答：它既保留旧版本又推迟全局可回收与冻结边界，使空间和事务标识风险同时累积。

1.7 B-Tree（平衡树索引）、Hash（哈希索引）、GIN（通用倒排索引）、GiST（通用搜索树）与 BRIN（块范围索引）

索引是以额外写入、存储和维护换取特定访问路径。B-Tree（平衡树索引）支持等值、范围、有序输出和前缀约束，是常见默认；Hash（哈希索引）聚焦等值匹配，不提供排序与范围能力；GIN（通用倒排索引）把一个值拆成多个键并维护倒排项，适合数组、文档或全文包含查询，但更新和待合并结构有成本；GiST（通用搜索树）是可扩展搜索框架，可表达范围、几何、相似等操作，可能返回候选后复核；BRIN（块范围索引）保存 page（页）范围摘要，体积小，适合物理顺序与过滤列高度相关的大表。多列索引受列顺序和查询形状约束，partial index（部分索引）只覆盖谓词子集，expression index（表达式索引）保存计算结果。

flowchart TD
    Q["查询谓词与排序"] --> E{"访问需求"}
    E -->|"等值 范围 排序"| B["平衡树索引"]
    E -->|"纯等值"| H["哈希索引"]
    E -->|"多值包含 全文"| G["通用倒排索引"]
    E -->|"范围 空间 相似"| S["通用搜索树"]
    E -->|"大表且物理相关"| R["块范围索引"]
    B --> C["候选行或有序结果"]
    H --> C
    G --> C
    S --> C
    R --> C
    C --> V["必要时回表与条件复核"]

图解：节点由查询需求分流到五类索引，再汇入候选结果和回表复核，箭头表示能力匹配而非产品推荐。前提是操作符类、数据分布和查询形状已知；正常路径用最小索引缩小候选；失败路径是低选择率、错误列序、摘要相关性差或写入成本超过收益；业务结论是索引评审必须同时给出被加速查询、写放大、占用空间和淘汰条件。

数据演绎 8：1000 万行选择率。 WMS（仓储管理系统）出库单表 1000 万行，status='DONE' 占 920 万行，单列 B-Tree（平衡树索引）即使能定位，也可能因大量回表比顺序扫描更贵；warehouse_id=17 AND status='PENDING' 只有 8000 行，合适的多列或 partial index（部分索引）可能显著减少 page（页）访问。若查询还按 created_at 排序取前 100 行，列顺序应围绕等值前缀、范围与排序联合验证，不能只按字段选择率独立排序。

热门面试题

1. 问题（基础题）：为什么 B-Tree（平衡树索引）最常用？
   • 考点：等值、范围和顺序能力。
   • 回答思路：以访问路径覆盖面解释，不说“永远最快”。
   • 详细答案：B-Tree（平衡树索引）能沿有序键定位等值和范围，并可按索引顺序输出，适配大量事务查询；但低选择率、大量回表或不匹配的多列前缀可能让优化器选择顺序扫描。它是通用能力强，不是所有查询的固定答案。
   • 进阶追问：Hash（哈希索引）为何不能替代？
   • 进阶回答：Hash（哈希索引）聚焦等值桶定位，不提供范围与顺序输出，是否有收益还要实测写入、缓存和数据分布。
2. 问题（原理题）：BRIN（块范围索引）何时有效？
   • 考点：物理相关性与范围摘要。
   • 回答思路：说明小体积来自只存块级摘要。
   • 详细答案：当过滤列与 heap（堆表）物理顺序高度相关，例如轨迹时间近似追加，BRIN（块范围索引）可用很小摘要排除大量 page（页）范围；若值随机散布，每个范围都覆盖很宽，候选 page（页）过多，收益会显著下降。
   • 进阶追问：它能返回精确行吗？
   • 进阶回答：通常先筛块范围，再访问 heap（堆表）复核具体 tuple（元组），不能把摘要当精确行索引。
3. 问题（场景题）：如何评审 partial index（部分索引）？
   • 考点：谓词覆盖、查询匹配与生命周期。
   • 回答思路：用待处理小集合和状态迁移说明。
   • 详细答案：例如异步导出仅 0.5% 任务处于待执行，可为稳定谓词建立 partial index（部分索引），减少体积和写入；但查询条件必须能推出索引谓词，状态迁移会写入或移出索引。评审要验证计划命中、参数化条件、状态分布和失效后的删除策略。
   • 进阶追问：部分索引能保证全表唯一吗？
   • 进阶回答：只能在其谓词覆盖集合内表达约束，不能把子集唯一性外推到全部业务行。

1.8 statistics（统计信息）、selectivity（选择率）、cost model（成本模型）与扫描路径

PostgreSQL（关系型数据库）是 cost-based optimizer（成本优化器），不是按固定规则“有索引就走索引”。statistics（统计信息）描述行数、不同值、常见值、直方图、空值和相关性；selectivity（选择率）估算谓词保留比例；cost model（成本模型）把顺序 page（页）、随机 page（页）、处理器运算、并行和缓存假设换算为可比较代价。顺序扫描适合读取较大比例；索引扫描适合少量定位；bitmap scan（位图扫描）先合并索引命中并按 heap（堆表）page（页）批量访问，适合中等命中或多条件组合；index-only scan（仅索引扫描）还要求所需列在索引中，且 VM（可见性映射）允许跳过多数 heap（堆表）可见性检查。

flowchart LR
    Q["查询条件"] --> S["统计信息"] --> E["行数与选择率估算"]
    E --> C["成本模型比较"]
    C --> A["顺序扫描"]
    C --> I["索引扫描"]
    C --> B["位图扫描"]
    C --> O["仅索引扫描"]
    A --> X["实际行数 缓冲 时间"]
    I --> X
    B --> X
    O --> X
    X -. "偏差反馈" .-> S

图解：节点从查询、统计、估算、成本比较到四类扫描，再由实际执行反馈，箭头表示优化器决策链。前提是统计样本和参数能代表当前数据；正常路径的估算与实际接近；失败路径是数据倾斜、列相关、参数差异或缓存冷热导致估算和代价失真；业务结论是计划争议要用 EXPLAIN (ANALYZE, BUFFERS) 的估算行、实际行和缓冲证据闭环，不能强行套索引经验。

数据演绎 9：statistics（统计信息）偏差与缓存冷热。 跨境物流表 5000 万行，统计估算某国家异常件 500 行，实际为 80 万行。优化器据此选择索引扫描并进行大量随机回表，冷缓存读取 12 万个 page（页）耗时 9 秒；第二次因缓存命中只需 1.2 秒，容易被误判为“优化完成”。更新统计并建立列间扩展统计后，估算接近 76 万行，计划改用 bitmap scan（位图扫描）或顺序扫描。回归必须分别测冷、热窗口，并记录实际行数和缓冲命中。

热门面试题

1. 问题（基础题）：为什么有索引仍走顺序扫描？
   • 考点：返回比例、回表与成本比较。
   • 回答思路：从总 page（页）访问而非索引存在性回答。
   • 详细答案：若谓词返回大比例行，索引定位后仍需访问大量分散 heap（堆表）page（页），随机回表和索引遍历可能比连续扫描更贵；小表本身也可能一次读完。应比较估算行、实际行、page（页）命中和排序需求，不能把顺序扫描等同异常。
   • 进阶追问：关闭顺序扫描能验证吗？
   • 进阶回答：可在隔离环境作为对照，不应当作长期修复；根因仍可能是统计、查询形状或索引设计。
2. 问题（原理题）：index-only scan（仅索引扫描）为何仍可能访问 heap（堆表）？
   • 考点：索引覆盖与 VM（可见性映射）。
   • 回答思路：区分列覆盖和可见性确认。
   • 详细答案：索引包含所需列只解决取值，MVCC（多版本并发控制）可见性仍需确认。VM（可见性映射）标记 page（页）全可见时可跳过 heap（堆表）；高频更新后标记被清除，就要回表检查，因此计划名称不保证零 heap（堆表）访问。
   • 进阶追问：如何提高真实收益？
   • 进阶回答：降低无意义更新、保证清理及时并验证全可见比例，同时控制覆盖列带来的索引体积和写放大。
3. 问题（场景题）：同一 SQL（结构化查询语言）今天突然换计划怎么办？
   • 考点：计划漂移证据链。
   • 回答思路：比较数据、统计、参数、缓存与版本环境。
   • 详细答案：保存前后计划、估算行与实际行、缓冲、排序和临时读写；再对齐统计更新时间、数据分布、参数值、索引状态和配置变更。止血可限定并发或使用已验证查询改写，长期修复统计、索引或数据模型，并用代表性参数集回归。
   • 进阶追问：只固定旧计划是否足够？
   • 进阶回答：不足，旧计划可能只适合旧分布；固定只能作为有退出条件的短期措施，仍需消除估算或成本失真。

1.9 Join（连接）算法、排序、聚合与磁盘溢写

Nested Loop（嵌套循环）让外表每行驱动内表访问，适合外表很小且内表有高效索引；Hash Join（哈希连接）通常把较小输入构建哈希表，再扫描另一输入探测，适合等值连接；Merge Join（归并连接）要求两侧按连接键有序，可利用现成顺序或先排序，适合大规模有序合并。排序、Hash Join（哈希连接）和哈希聚合都受工作内存约束，而且内存预算往往按执行节点、并行工作者和并发查询放大；不足时会分批或写临时文件。EXPLAIN (ANALYZE, BUFFERS) 要观察循环次数、每次实际行、排序方法、批次数与临时块，避免只看总耗时。

sequenceDiagram
    participant P as 优化器
    participant O as 外表
    participant I as 内表
    participant M as 工作内存
    participant D as 临时磁盘
    P->>O: 选择连接顺序
    alt 嵌套循环
        loop 外表每行
            O->>I: 索引定位匹配行
        end
    else 哈希连接
        I->>M: 构建哈希表
        O->>M: 逐行探测
        M--xD: 内存不足时分批溢写
    else 归并连接
        O->>M: 获取或排序有序输入
        I->>M: 获取或排序有序输入
        M--xD: 排序超限写临时文件
    end

图解：节点包括优化器、两侧输入、工作内存和临时磁盘，箭头展示三种 Join（连接）及两条溢写路径。前提是估算行与连接条件可信；正常路径按输入规模和顺序选择算法；失败路径是外表估小导致循环爆炸、哈希分批或排序落盘；业务结论是异步导出应控制并发和查询形状，内存参数不能按单查询孤立放大。

数据演绎 10：排序与磁盘溢写。 8 个并发异步导出，每个计划含 2 个排序节点和 1 个 Hash Join（哈希连接），每节点可使用 64 MiB（兆字节），理论瞬时工作内存上限已接近 8*3*64=1536 MiB（兆字节），并行工作者还可能继续放大。某排序输入 1200 万行、键与行指针合计 48 B（字节），原始就约 549 MiB（兆字节），64 MiB（兆字节）下需外部归并并产生临时读写。若只把参数调到 1 GiB（吉字节），8 个任务并发可把主机推向内存压力；更稳妥的是限制导出并发、缩小投影与预过滤，并独立监控临时文件和总内存。

热门面试题

1. 问题（基础题）：三种 Join（连接）算法如何选择？
   • 考点：输入规模、连接条件、索引与顺序。
   • 回答思路：给出适用前提和失败反例。
   • 详细答案：Nested Loop（嵌套循环）适合小外表驱动高效点查；Hash Join（哈希连接）适合等值连接且构建侧可控；Merge Join（归并连接）适合两侧已有顺序或大规模有序合并。最终由成本模型比较，估算错误会让正确算法在错误规模上退化。
   • 进阶追问：非等值连接能否用 Hash Join（哈希连接）？
   • 进阶回答：其核心依赖等值哈希匹配，其他条件通常需要不同路径或作为附加过滤，具体操作符支持要以计划验证。
2. 问题（原理题）：为何工作内存不能直接调很大？
   • 考点：按节点、工作者与并发放大。
   • 回答思路：给出乘法模型而非单查询视角。
   • 详细答案：一个查询可能有多个排序、哈希或聚合节点，并行计划还有多个工作者；多个会话同时执行时，总需求近似按节点数、工作者和并发数相乘。过大参数可能减少单次溢写，却把系统推向交换、进程终止或全局抖动。
   • 进阶追问：怎样安全验证调整？
   • 进阶回答：在代表性并发下记录计划节点、临时块、进程总内存和尾延迟，设置回滚阈值，不以单查询最快为唯一目标。
3. 问题（场景题）：异步导出把交易库拖慢如何止血？
   • 考点：资源隔离与权威边界。
   • 回答思路：先限并发和时间窗，再优化查询或迁移读模型。
   • 详细答案：暂停低优先级任务、限制导出并发和单任务范围，保护支付与库存连接池；用计划、临时文件、磁盘延迟和锁等待两类以上证据确认扫描或溢写。长期做分页水位、预聚合或专用只读副本，但副本落后时不能导出未经标注的新鲜度。
   • 进阶追问：直接切副本有什么风险？
   • 进阶回答：可能读到未重放数据并继续制造磁盘压力，必须核对目标水位、查询容量和故障回源策略。

1.10 行锁、表锁、死锁、隔离级别与 SSI（可串行化快照隔离）

PostgreSQL（关系型数据库）的普通查询主要靠 MVCC（多版本并发控制）读取版本，行级写冲突和显式锁则由锁管理器协调；架构变更、维护与普通语句还会申请不同强度的表级锁。Read Committed（读已提交）通常每条语句取得新 snapshot（快照），同一事务两次查询可见集合可能变化；Repeatable Read（可重复读）让事务使用稳定 snapshot（快照），但并发写冲突可能要求事务回滚重试；Serializable（可串行化）在快照隔离基础上通过 SSI（可串行化快照隔离）跟踪读写依赖，发现可能形成不可串行化环时中止参与者。死锁是等待图成环，数据库会选择事务失败；锁等待只是边仍有机会解除。

sequenceDiagram
    participant A as 库存事务甲
    participant B as 库存事务乙
    participant L as 锁管理器
    participant S as 依赖检测
    A->>L: 锁定商品一
    B->>L: 锁定商品二
    A->>L: 请求商品二
    L--xA: 等待事务乙
    B->>L: 请求商品一
    L--xB: 等待事务甲
    L->>S: 等待图形成环
    S-->>B: 中止一个事务
    L-->>A: 解除等待并继续

图解：节点是两个库存事务、锁管理器与依赖检测器，箭头构造相反加锁顺序形成的等待环。前提是两个事务都持锁并请求对方资源；正常路径应统一商品排序加锁并尽快提交；失败路径由死锁检测中止一方，SSI（可串行化快照隔离）则可能在没有传统阻塞环时因读写依赖中止事务；业务结论是应用必须把可重试错误纳入幂等边界，不能把数据库自动中止当作数据丢失。

热门面试题

1. 问题（基础题）：锁与 MVCC（多版本并发控制）的边界是什么？
   • 考点：版本读取与并发修改协调。
   • 回答思路：用普通查询、行更新和架构变更区分。
   • 详细答案：MVCC（多版本并发控制）决定 snapshot（快照）能看到哪些 tuple（元组），让普通读通常不必等待正在修改的事务；锁保护并发写、显式一致性要求和 relation（关系）级操作。读写并发并非完全无锁，查询仍持有必要表锁，资源与架构冲突也会等待。
   • 进阶追问：读已提交能避免丢失更新吗？
   • 进阶回答：不能只凭隔离级别保证业务不变量，应使用条件更新、行锁、唯一约束或可串行化事务并处理冲突。
2. 问题（原理题）：SSI（可串行化快照隔离）为何会主动中止事务？
   • 考点：读写依赖与可串行化环。
   • 回答思路：说明它不是把所有查询都串行加锁。
   • 详细答案：SSI（可串行化快照隔离）允许事务先按 snapshot（快照）并发执行，同时记录可能影响串行顺序的读写依赖；当依赖组合可能形成危险结构时，中止一个事务，避免提交出无法对应任何串行顺序的结果。应用必须安全重试完整事务。
   • 进阶追问：重试单条失败语句可以吗？
   • 进阶回答：通常应从事务边界重试，因为旧 snapshot（快照）和已做决策不能沿用，并要保证外部副作用幂等。
3. 问题（场景题）：如何治理库存死锁？
   • 考点：等待图、加锁顺序与事务范围。
   • 回答思路：保存参与语句和锁对象，再统一顺序。
   • 详细答案：先按死锁日志还原事务、锁模式、对象和语句顺序，再用锁视图与业务请求标识交叉；止血可重试被中止事务并限制冲突批次。长期按稳定商品或库位顺序加锁、缩短事务、把远程调用移出持锁区，并回归并发调拨和取消场景。
   • 进阶追问：提高超时能解决吗？
   • 进阶回答：不能，等待环不会因更长超时自行解除，反而延长资源占用；应消除相反顺序或缩小冲突集合。

1.11 写放大、缓存、复制水位与容量模型

一次业务更新可能同时产生新 heap（堆表）tuple（元组）、旧版本、多个索引项、WAL（预写日志）、full-page write（整页写）、副本传输、归档和后续 VACUUM（空间回收）读写。shared buffers（共享缓冲区）命中高只说明部分 page（页）在数据库缓存中，不代表查询高效：全表扫描也能把热点缓存挤走，操作系统缓存和存储缓存还在另一层。复制要分别记录日志生成、发送、接收、持久化和重放 LSN（日志序列号）；副本连接正常不等于可见新提交。容量应按稳态、峰值、维护、故障追赶和关系重写预留，而不是只按净业务数据增长。

flowchart LR
    U["一次业务更新"] --> H["堆表新版本"]
    U --> I["五个二级索引"]
    U --> W["预写日志与整页镜像"]
    W --> R["副本传输与重放"]
    H --> V["后续空间回收"]
    I --> V
    H --> C["共享缓冲区与数据页刷盘"]
    I --> C
    V --> D["磁盘与处理器成本"]
    R --> D
    C --> D

图解：中心节点是一笔业务更新，箭头展开 heap（堆表）、五个索引、WAL（预写日志）、副本、缓存刷页和后续清理成本。前提是更新命中现有行且索引配置已知；正常路径的放大可被容量吸收；失败路径是 HOT（堆内更新）失效、检查点整页镜像增加、副本重放落后或清理追不上；业务结论是新增索引必须用读收益抵偿完整生命周期成本，而不是只看创建后单次查询变快。

数据演绎 11：五个索引与副本延迟。 支付状态表每秒更新 5000 行，每个 heap（堆表）新版本 220 B（字节），5 个索引平均每项 40 B（字节），忽略页级额外开销时，仅 tuple（元组）与索引净变化流量就约 5000*(220+5*40)=2.0 MB/s（兆字节每秒）；再叠加旧版本、WAL（预写日志）、整页镜像和双副本，实际介质与网络写入更高。高峰 WAL（预写日志）生成 80 MiB/s（兆字节每秒），副本只能重放 50 MiB/s（兆字节每秒），10 分钟位置差累计约 18 GiB（吉字节）；连接始终正常，但副本查询可见时间持续落后，必须限流重查询或扩充重放能力。

热门面试题

1. 问题（基础题）：一条更新为何不是一次磁盘写？
   • 考点：heap（堆表）、索引、日志、副本和清理生命周期。
   • 回答思路：沿即时写入和延迟维护两条链解释。
   • 详细答案：更新创建新 tuple（元组）并留下旧版本，可能修改多个索引，生成 WAL（预写日志）和整页镜像，再由数据页刷盘、日志归档与副本重放持久化；旧版本最后还要 VACUUM（空间回收）。所以写放大既有提交前成本，也有后台延迟成本。
   • 进阶追问：HOT（堆内更新）能消除 WAL（预写日志）吗？
   • 进阶回答：不能，它主要减少索引维护并改善版本链局部性，heap（堆表）变化和恢复所需日志仍存在。
2. 问题（原理题）：缓存命中率高为何仍可能慢？
   • 考点：扫描量、锁、处理器和缓存层误判。
   • 回答思路：说明“来自内存”不等于“访问少”。
   • 详细答案：查询可能从 shared buffers（共享缓冲区）读取数百万 page（页），虽然命中率高，却消耗处理器、内存带宽并驱逐真正热点；它还可能慢在锁、排序、哈希或返回网络。应看实际 page（页）数、行数、循环和等待，而非单一百分比。
   • 进阶追问：命中率低一定是内存不足吗？
   • 进阶回答：不一定，批量扫描、冷启动、低复用访问和操作系统缓存都会改变指标，需要结合工作集和物理读延迟。
3. 问题（场景题）：副本延迟时如何保护业务？
   • 考点：水位、读新鲜度与降级。
   • 回答思路：先识别生成快还是重放慢，再按业务分级。
   • 详细答案：比较发送、接收、刷新与重放 LSN（日志序列号）及字节速率，判断网络、存储、长查询或恢复冲突。支付查单和库存裁决回权威节点；报表标注水位或暂停；止血限制副本重查询并保留日志，修复后验证追平时间和故障切换容量。
   • 进阶追问：追平后立刻恢复全部读流量吗？
   • 进阶回答：先确认重放稳定、缓存回暖和关键业务版本一致，再灰度恢复，避免读流量重新把副本压入落后。

1.12 慢查询、膨胀、长事务、清理落后与计划漂移排障

维护排障先确认业务影响与权威数据，再建立数据库证据和主机或应用侧独立证据。止血必须可回滚，修复必须改变根因，回归必须复用原查询、原负载或故障注入。以下九类问题不可只用单指标定性：慢查询可能是锁或计划，膨胀可能是长事务或复用不足，WAL（预写日志）增长可能是生成变多或保留责任未消费，缓存命中变化也可能只是工作集变化。

flowchart TD
    I["业务影响与时间窗"] --> A["活动语句 锁 事务"]
    A --> P["实际计划与缓冲"]
    A --> V["死版本 清理 年龄"]
    A --> W["日志 检查点 副本水位"]
    P --> H{"两类证据是否闭环"}
    V --> H
    W --> H
    H -->|"否"| K["保留现场并验证竞争假设"]
    H -->|"是"| S["可回滚止血"]
    S --> F["根因修复"] --> R["原负载与故障回归"]

图解：节点从业务影响分到语句计划、版本清理和日志复制，再汇总到证据门禁，箭头规定排障顺序。前提是先保存时间窗、实例和发布信息；正常路径用两类独立证据进入止血、修复和回归；失败路径是证据不足时直接重启、删日志或重建索引；业务结论是恢复速度与证据质量同等重要，权威交易链必须在任何维护动作前确认结果边界。

sequenceDiagram
    participant O as 值班人员
    participant D as 数据库
    participant A as 应用监控
    participant S as 存储监控
    O->>A: 固定影响范围和时间窗
    O->>D: 保存事务 锁 计划 清理与水位
    O->>S: 获取延迟 吞吐 空间证据
    alt 两类证据一致
        O->>D: 执行可回滚止血
        D-->>A: 业务指标恢复
        O->>D: 实施根因修复
        O->>A: 原流量与失败场景回归
    else 证据冲突
        O->>O: 保留竞争假设
        O->>D: 做低风险最小验证
    end

图解：节点是值班人员、数据库、应用与存储监控，箭头展示两类证据对齐后的处置闭环。前提是采样动作风险可控；正常路径先恢复业务再修根因；失败路径是数据库指标和外部证据冲突，此时保留假设而非强行归因；业务结论是单次 EXPLAIN 输出或单张监控图都不足以宣布根因，回归必须覆盖原失败窗口。

数据演绎 12：索引构建空间峰值与回归。 生产 heap（堆表）800 GiB（吉字节），拟建索引估算 260 GiB（吉字节），当前可用 420 GiB（吉字节）。若构建过程还需排序临时空间 180 GiB（吉字节）、WAL（预写日志）保留增加 120 GiB（吉字节），理论峰值新增 560 GiB（吉字节），已经超过余量；副本重放落后还会继续保留日志。止血不是冒险开建后删文件，而是缩小并发、扩容或分窗口实施，记录 heap（堆表）扫描、临时空间、WAL（预写日志）与副本水位；回归除查询收益外，还要验证写延迟、清理和故障恢复空间。

热门面试题

1. 问题（基础题）：慢查询排查为何要两类证据？
   • 考点：数据库内部与外部责任边界。
   • 回答思路：用锁等待、存储慢和应用排队反例说明。
   • 详细答案：实际计划能说明行数、扫描、缓冲和临时文件，却未必证明磁盘为何慢或应用是否先排队；数据库等待也需存储、处理器或调用链交叉。两类独立证据能排除相关但非因果信号，并让止血动作指向正确责任对象。
   • 进阶追问：两次相同命令算两类吗？
   • 进阶回答：不算，那只是同一观察面的重复采样；应引入另一层或另一机制的独立信号。
2. 问题（原理题）：如何区分膨胀和正常增长？
   • 考点：业务净数据、死版本与空间复用。
   • 回答思路：比较活行、更新删除、尺寸和复用趋势。
   • 详细答案：正常增长应与业务行数、行宽和索引项同步；膨胀表现为尺寸增长显著超过活数据，伴随死 tuple（元组）、低页密度、长事务或清理落后。还要看删除后空间是否被新写复用，不能把文件未缩小直接等同持续膨胀。
   • 进阶追问：重建后变小就证明根因解决了吗？
   • 进阶回答：没有，重建只处理结果；若长事务、更新模式或清理资源不变，膨胀还会再次出现。
3. 问题（场景题）：计划漂移事故如何回归？
   • 考点：参数矩阵、冷热缓存与统计稳定性。
   • 回答思路：覆盖高低选择率和峰值并发。
   • 详细答案：保存事故参数、旧新计划与数据快照，选择高频值、稀有值和边界时间段分别在冷、热缓存及代表性并发下执行，比较估算、实际行、缓冲、临时读写和尾延迟。修复后还要模拟统计更新与数据增长，确认不会迅速回漂。
   • 进阶追问：回归只看平均耗时够吗？
   • 进阶回答：不够，应看尾延迟、资源总量、计划稳定性和对交易写入的影响，并保留回滚阈值。

1.13 设计思想、项目边界与版本核对卡

PostgreSQL（关系型数据库）以 heap（堆表）和索引分离换来多种访问路径与独立索引设计，代价是更新可能同时维护多个 relation（关系）；MVCC（多版本并发控制）把读写阻塞转化为旧版本、VACUUM（空间回收）和 freeze（冻结）成本；WAL（预写日志）把逐事务随机数据页写转化为顺序恢复日志，再由后台组织 page（页）刷盘；cost-based optimizer（成本优化器）基于统计与成本选择路径，而不是固定规则。空间删除后可复用与文件归还操作系统是不同目标。支付资金、库存守恒和 Runner（执行器）租约等不变量必须由交易主库约束、事务、幂等与审计裁决；搜索、分析和副本只承担读模型。

flowchart LR
    C["业务命令"] --> P["关系型交易主库"]
    P --> I["约束 事务 幂等 审计"]
    I --> E["提交后事件"]
    E --> S["搜索读模型"]
    E --> A["分析与时序读模型"]
    E --> R["只读副本"]
    S -. "降级回源" .-> P
    A -. "校验与重建" .-> E
    R -. "水位不足" .-> P

图解：节点把业务命令、交易主库、不变量和三个派生读取分开，实线箭头表示权威提交后投影，虚线表示降级、校验和水位不足时回源。前提是事件包含业务键、版本与删除语义；正常路径由主库裁决后扩展读取；失败路径是投影落后、重复或重建，此时禁止反向覆盖权威事实；业务结论是交易不变量不能交给搜索或分析副本，异构系统的价值来自职责分离而非替换权威源。

正式图解：参与者覆盖客户端、后端进程、shared buffers（共享缓冲区）、WAL buffer（预写日志缓冲区）、WAL（预写日志）文件、并发查询、autovacuum（自动清理）、长事务、heap（堆表）与恢复进程；箭头同时表现提交日志先行、snapshot（快照）查询、长事务阻塞回收、checkpoint（检查点）刷页和崩溃重放。前提是版本与持久化配置已经现场核对；正常路径提交后查询按快照选版本并由后台回收；失败路径包括响应未知、旧快照拖延清理和数据页未落盘时崩溃；业务结论是“提交、可见、可回收、已缩文件、已复制”是五个不同断言，必须分别举证。

版本核对卡：项目实际版本为“待现场核对”。上线或面试引用版本敏感结论前，记录服务器版本、操作系统与文件系统、关键持久化参数、page（页）大小、复制与归档拓扑、扩展、统计配置、清理阈值、检查点设置、隔离级别、官方手册章节、最小复现实验、核对日期与回退条件。跨版本稳定机制包括 WAL（预写日志）先行、MVCC（多版本并发控制）版本可见性、heap（堆表）与索引分离、成本优化和空间回收职责；默认值、监控字段、具体锁语义、索引能力细节和参数效果均以目标环境官方手册和实验为准。

热门面试题

1. 问题（基础题）：为什么说 heap（堆表）与索引分离是一种取舍？
   • 考点：多访问路径与写维护成本。
   • 回答思路：同时回答查询灵活性和版本更新代价。
   • 详细答案：独立索引 relation（关系）允许同一 heap（堆表）按多个键和操作符建立访问路径，不必按单一主键组织数据；但 tuple（元组）跨页更新或索引键变化会维护多个索引，死版本还要清理。设计目标是用真实高价值查询抵偿写入与维护成本。
   • 进阶追问：索引越少越好吗？
   • 进阶回答：也不是，缺少必要索引会放大扫描、锁持有和资源占用；应按读写工作负载、约束和故障恢复综合选择。
2. 问题（原理题）：WAL（预写日志）如何改变随机写问题？
   • 考点：提交日志先行与后台数据页组织。
   • 回答思路：说明转换而非消灭写入。
   • 详细答案：事务不必在响应前把所有分散 heap（堆表）和索引 page（页）逐一持久化，而是先顺序追加可重放 WAL（预写日志）并确认；数据页以后由后台写入和 checkpoint（检查点）落盘。随机页写并未消失，只是从提交关键路径转移并可被批量平滑。
   • 进阶追问：因此磁盘只需擅长顺序写吗？
   • 进阶回答：不能，查询随机读、数据页刷写、临时文件、清理和恢复仍要求综合输入输出能力。
3. 问题（场景题）：何时把 PostgreSQL（关系型数据库）保留为权威源？
   • 考点：交易不变量与派生读模型边界。
   • 回答思路：用支付、库存、任务租约和物流事实回答。
   • 详细答案：需要跨行约束、条件更新、唯一性、可审计事务和确定恢复的支付、库存与任务租约应留在 PostgreSQL（关系型数据库）权威边界；复杂搜索、全历史聚合和低延迟看板可投影到专用系统。投影必须有版本、水位、校验、回源和重建路径。
   • 进阶追问：交易表很大就应直接换搜索系统吗？
   • 进阶回答：不能按体量直接替换，应先拆查询形状、冷热数据和不变量；搜索系统承接检索，不接管资金或库存裁决。

以上恰好 13 个带知识标记的三级标题，每节 3 道六字段题，共 39 道。以下只是综合题、项目话术与复习入口，不再计入知识型三级标题。

2. 综合口述题库

1. 问题：请完整解释 PostgreSQL（关系型数据库）从逻辑对象到物理 tuple（元组）的层级。

   • 口述答案：我先给结论：访问一行业务数据不是从“表名”直接跳到磁盘行，而是经过服务管理、命名空间、relation（关系）、文件和 page（页）多层映射。一个 cluster（集群实例）由一组服务进程管理数据目录，内部可有多个 database（数据库）；连接先确定 database（数据库），再由 schema（模式）和搜索路径解析 relation（关系）。table（表）与 index（索引）都是独立 relation（关系），各自可能有主数据、FSM（空闲空间映射）、VM（可见性映射）等 fork（分支文件）；大文件再拆成 segment（文件段），segment（文件段）由 page（页）组成，heap（堆表）page（页）通过行指针定位 tuple（元组）版本。假设库存流水主 relation（关系）为 2.4 GiB（吉字节），看到多个文件并不表示有多份表，还要汇总索引和 TOAST（超大字段存储）。失败边界包括连接错 database（数据库）、同名 schema（模式）解析错误、只看文件名误删附属对象。项目中我会用全限定名、对象标识和尺寸增量定位 WMS（仓储管理系统）增长源，并把索引、TOAST（超大字段存储）和清理状态一起纳入容量。验证闭环是从系统目录确认对象，映射 relation（关系）文件，再用页和执行计划证据确认实际访问，绝不直接操作受管理的数据文件。 面试中我还会强调 database（数据库）是连接与系统目录边界，schema（模式）只是库内命名空间；segment（文件段）是单 relation（关系）的文件拆分，不提供路由或副本。这样既能回答对象定位，也能避免把存储术语误讲成分布式能力。线上若尺寸与预期不符，我会先比对对象标识、全限定名和附属 relation（关系），再判断是净数据、索引还是版本膨胀。
   • 追问：cluster（集群实例）是否表示自动分片？
   • 直接回答：不表示，这里首先是一个服务进程组管理的数据目录，分布式能力要另行核对架构。
   • 追问：索引是否存放在 heap（堆表）内部？
   • 直接回答：不是，索引自身是 relation（关系），通过物理定位关联 heap（堆表）版本。
   • 追问：排障为何要记录全限定名？
   • 直接回答：搜索路径可能命中同名对象，不记录 database（数据库）和 schema（模式）就无法证明访问目标。
   • 详情：对象层级

2. 问题：请解释 page（页）布局以及 FSM（空闲空间映射）、VM（可见性映射）和 TOAST（超大字段存储）如何协作。

   • 口述答案：核心结论是 page（页）负责实际行版本，三个辅助结构分别解决选空间、跳可见性检查和安置大字段，不能互相替代。heap（堆表）page（页）从前部保存页头与行指针，从尾部保存 tuple（元组），中间是可用空间；行指针提供稳定槽位，让页内整理不必改写所有外部引用。FSM（空闲空间映射）近似记录哪些 page（页）还有空间，插入可先查它而不是扫描全表；VM（可见性映射）记录 page（页）全可见或全冻结，使 index-only scan（仅索引扫描）可能跳过 heap（堆表）并让 VACUUM（空间回收）跳过安全 page（页）；TOAST（超大字段存储）先尝试压缩，再把超大变长值拆片到附属 relation（关系）。以 8 KiB（千字节）page（页）为例，扣除头、行指针、tuple（元组）头和对齐后，平均 180 B（字节）的行只能容纳约四十多条，不是简单用 8192 除业务字段长度。WMS（仓储管理系统）列表若不取 20 KiB（千字节）备注，主行较窄会很快；详情读取则可能访问拆片并解压。验证要看投影列、heap（堆表）访问、全可见比例和缓冲块；失败时分别排除 VM（可见性映射）失效、宽行随机读和 FSM（空闲空间映射）空间估算不足。 对更新路径还要补一层：原 page（页）有空间且索引条件允许时，新版本更可能留在同页；空间不足则跨页并增加索引维护。维护后 VM（可见性映射）何时重新全可见，直接影响同一条覆盖查询的真实回表量。因此容量评估既看平均行宽，也要看更新频率、页内预留、清理水位和大字段读取比例，不能用表总行数粗估延迟。
   • 追问：FSM（空闲空间映射）是精确字节账本吗？
   • 直接回答：不是，它是帮助选 page（页）的近似辅助信息，最终分配仍以实际 page（页）为准。
   • 追问：索引覆盖列就一定不回表吗？
   • 直接回答：不一定，还要由 VM（可见性映射）证明对应 page（页）全可见。
   • 追问：TOAST（超大字段存储）是否总把大值移出？
   • 直接回答：不能绝对化，它会结合存储策略、压缩和行大小处理，具体行为以目标环境实验为准。
   • 详情：页与辅助结构

3. 问题：一次写入从 SQL（结构化查询语言）到提交成功经历什么？

   • 口述答案：我会把路径拆成语句处理、内存修改、日志承诺和后续持久化四段。后端进程先做 parse（解析）、rewrite（重写）、plan（计划）与 execute（执行），找到目标 tuple（元组）并取得必要锁；执行器在 shared buffers（共享缓冲区）中修改 heap（堆表）和索引 page（页），同时在 WAL buffer（预写日志缓冲区）追加 WAL（预写日志）记录并分配 LSN（日志序列号）。提交时，多事务可通过 group commit（组提交）共享 fsync（强制刷盘），当本事务提交记录越过配置要求的持久化位置后才向客户端确认。此时数据 page（页）可以仍是脏页，随后由后台写入或 checkpoint（检查点）落盘；副本还要经历接收、写入、刷新和重放才可见。假设 20 个事务同时等待 4 ms（毫秒）的日志刷新，group commit（组提交）可共享刷新成本，但任何一个事务都不能绕过自身提交日志的确认边界。支付或库存项目只把权威节点提交当本地事务完成，消息投影和副本读取另设水位。若响应在提交后丢失，结果是未知而非失败，应用按幂等键查流水。验证则对齐事务日志、LSN（日志序列号）、数据 page（页）刷出和副本重放四个时间点，不能用一个“成功”覆盖全部阶段。 插入、更新和删除的差别体现在 heap（堆表）版本与索引维护：插入创建新版本，更新通常创建新旧版本链，删除先标记当前版本失效；三者都遵守日志先行。若 synchronous_commit 等版本敏感配置改变确认条件，只能在版本卡中记录现场值、官方语义和断连实验，不能把教学默认当成所有环境事实。
   • 追问：提交成功等于 heap（堆表）page（页）已落盘吗？
   • 直接回答：不等于，默认重点是提交 WAL（预写日志）达到持久化要求，脏 page（页）可稍后刷出。
   • 追问：group commit（组提交）会牺牲原子性吗？
   • 直接回答：不会，它只是让多条提交日志共享刷新，每个事务仍有独立提交记录与状态。
   • 追问：副本连接正常就能写后读吗？
   • 直接回答：不能，还要确认副本已经重放到该提交对应的 LSN（日志序列号）。
   • 详情：写路径与完成时点

4. 问题：支付事务提交超时后，怎样处理未知结果而不重复扣款？

   • 口述答案：结论是超时只说明客户端没有在截止时间内拿到确定响应，不能推导数据库已回滚。服务端可能在 WAL（预写日志）持久化前断开，此时事务失败；也可能提交记录已 fsync（强制刷盘）而响应丢在网络上，此时权威事实已经成立；还可能连接中断后客户端无法立即确认。方案必须先设计业务幂等键，例如支付单号加动作类型受唯一约束，事务内写支付流水、状态迁移和审计记录。客户端遇到超时先查询权威写节点：查到已提交记录就返回原结果，确认无记录才重新发起，仍未知则进入渠道查单与对账，不能去异步副本判空。假设主库提交 LSN（日志序列号）为 900，副本只重放到 870，副本查不到并不表示未扣款。外部渠道调用还要与数据库事务分开治理，使用可重放事件、幂等调用和补偿记录，避免数据库回滚却渠道已成功。止血时暂停同幂等键新动作并保留流水、连接和日志时间线；长期修复明确超时、重试和查单状态机。回归要注入“提交前断连、提交后丢响应、副本延迟、重复回调”四类故障，证明金额守恒、流水唯一且最终结果可解释。 状态机还要显式区分“处理中、已成功、明确失败、结果未知、待对账”，每个迁移都记录原因和前一版本，避免超时重试把晚到成功覆盖成失败。监控同时统计同一幂等键命中旧结果的次数、未知状态停留时间和对账差异；只有这些指标在故障注入后收敛，才能证明方案不是把重复扣款风险藏进人工工单。 对账完成后还要把未知原因回填到发布与容量记录，区分数据库刷新慢、连接中断、应用截止时间过短和渠道延迟；下一轮压测按原因复现。只有未知比例、平均收敛时间、重复拦截数和资金差额同时满足门槛，才能恢复自动重试放量。
   • 追问：能否增加超时避免未知结果？
   • 直接回答：只能减少部分误超时，无法消除进程、网络或响应边界上的未知结果，幂等与查单仍必需。
   • 追问：为什么不能从副本判定失败？
   • 直接回答：副本可见晚于主库提交，判空会把复制延迟误当作未发生并触发重复扣款。
   • 追问：数据库事务能覆盖渠道扣款吗？
   • 直接回答：不能，外部副作用需要幂等、状态机、查单和对账补偿共同闭环。
   • 详情：写路径与完成时点

5. 问题：WAL（预写日志）、checkpoint（检查点）和 full-page write（整页写）如何共同完成崩溃恢复？

   • 口述答案：核心不变量是日志先于对应数据 page（页）持久化。事务修改 shared buffers（共享缓冲区）中的 page（页）时先产生 WAL（预写日志），提交记录达到持久化边界后即可确认；后台写入和 checkpoint（检查点）再把脏 page（页）写到数据文件。checkpoint（检查点）提供恢复起点，并推动此前脏页落盘；checkpoint（检查点）后某 page（页）第一次被修改时，full-page write（整页写）可保存完整镜像，防止崩溃恰逢存储只写入半个 page（页），导致增量日志没有可靠基线。恢复进程从检查点后的 LSN（日志序列号）读取日志，必要时先还原整页镜像，再重放后续变化，使已承诺但数据 page（页）尚未刷出的事务重新出现。假设 10 分钟产生 60 GiB（吉字节）脏页，若集中最后 90 秒写出，平均带宽需求超过 680 MiB/s（兆字节每秒），会与前台 fsync（强制刷盘）争用；平滑到 600 秒约 102 MiB/s（兆字节每秒）。检查点过密增加整页镜像和写尖峰，过疏增加恢复时间与 WAL（预写日志）保留。验证必须实际执行崩溃恢复演练并核对业务不变量，数据文件存在、进程能启动都不等于恢复链完整。 恢复完成后还要校验数据库一致性与业务一致性两层：数据库能开放连接只说明恢复流程结束，支付流水金额守恒、库存流水可重算、关键索引可用和副本重新追平才说明业务恢复。演练必须记录检查点位置、最后归档日志、重放终点、恢复时长和丢失窗口，以便与 RPO（恢复点目标）和 RTO（恢复时间目标）逐项对照。
   • 追问：full-page write（整页写）每次更新都记录整页吗？
   • 直接回答：不能这样概括，关键是 checkpoint（检查点）后的首次相关修改，细节以目标版本手册和实验为准。
   • 追问：checkpoint（检查点）越频繁恢复越好吗？
   • 直接回答：恢复范围可能缩短，但整页镜像和刷页成本会上升，需要在恢复目标和前台延迟间平衡。
   • 追问：WAL（预写日志）能替代备份吗？
   • 直接回答：不能，仍需独立基础备份、连续归档和隔离环境恢复验证。
   • 详情：日志与恢复

6. 问题：请用具体事务编号解释 MVCC（多版本并发控制）的可见性。

   • 口述答案：我用库存行逐步演绎。事务 100 插入 stock=10 并提交，初始 tuple（元组）是 xmin=100,xmax=0。事务 110 在 Repeatable Read（可重复读）下建立 snapshot（快照），其可见集合在事务期间保持稳定。事务 120 更新库存为 7：旧 tuple（元组）变为 xmin=100,xmax=120，新 tuple（元组）为 xmin=120,xmax=0，随后提交。事务 110 再读仍选旧版本 10，因为它的 snapshot（快照）早于事务 120 的可见提交；事务 130 在 Read Committed（读已提交）中新语句建立 snapshot（快照），会看到新版本 7。事务 140 尝试更新为 6 后回滚，它创建的 tuple（元组）因创建事务未提交而不可见；事务 150 删除当前行并提交，事务 160 新读看不到业务行，但物理旧版本仍占 heap（堆表）。这说明 xmin 与 xmax 只是可见性输入，还要结合事务提交状态、活动事务集合和 snapshot（快照）边界。项目上，WMS（仓储管理系统）读到旧库存可能是合法旧快照、读副本落后或缓存陈旧，必须记录查询节点、隔离级别与事务起点。验证通过两个并发会话复现编号顺序，再检查 tuple（元组）头和业务结果，不能只比较编号大小。 可见性之外还要单独讨论锁：事务 130 能读到版本 7，不代表它能无冲突地把库存改成 6；并发写仍要等待或检测冲突。若系统目录对事务状态的旧信息已被压缩，tuple（元组）头还会使用提示信息优化判断，但原始字段与标志细节属于版本核对项。面试表达应坚持“字段加事务状态加 snapshot（快照）”三部分，不背一条简化大小比较。
   • 追问：编号小的事务创建版本一定可见吗？
   • 直接回答：不一定，创建事务可能回滚或处于 snapshot（快照）的活动集合中。
   • 追问：删除提交后空间立刻释放吗？
   • 直接回答：不会，只是新 snapshot（快照）不可见，待旧快照退出并由 VACUUM（空间回收）处理后才可复用。
   • 追问：读到旧值是否说明丢提交？
   • 直接回答：不能直接判断，先核对快照、节点、复制水位和缓存层。
   • 详情：事务可见性

7. 问题：Read Committed（读已提交）与 Repeatable Read（可重复读）的 snapshot（快照）差异如何影响业务？

   • 口述答案：Read Committed（读已提交）通常让事务中的每条语句取得新 snapshot（快照），所以第一条查询看到库存 10，其他事务提交扣减后，第二条相同查询可能看到 7；它保证不读取未提交版本，但不保证整个事务内结果集合不变。Repeatable Read（可重复读）通常让事务复用稳定 snapshot（快照），两次普通查询仍看到 10，从而适合需要一致读取视图的计算；但它不意味着并发写都能静默成功，基于旧版本更新可能冲突并要求回滚重试。支付对账若要在多个查询间得到同一时点集合，可使用稳定 snapshot（快照），但事务过长会保留旧 tuple（元组）并拖慢 VACUUM（空间回收）；库存扣减则更应以条件更新、唯一约束或明确行锁保护业务不变量，不能只提升隔离级别。举例：事务甲先查 stock=1，事务乙也查到 1，若应用都在内存减一再无条件写回，隔离名称本身不能替代原子条件 stock>0。失败边界还包括序列化错误、死锁和副本只读语义。验证应并发运行读、写和重试脚本，记录每条语句 snapshot（快照）与最终守恒关系，并确认回滚后外部消息不会重复发送。 两种隔离都不能替代端到端幂等：事务因死锁或并发冲突回滚后，应用可能需要重试，而事务外已经发出的消息或远程调用不会自动撤销。我的实现会先在本地事务记录待发布事件，提交后再投递；重试使用同一业务键。回归除了数据库最终值，还核对事件次数、外部副作用和回滚日志，确保提升隔离不会制造重复执行。 对同一事务的关键读取，我会在日志中记录隔离级别、业务版本和事务起点，出现争议时才能复现当时快照，而不是拿事故后的新查询替代现场。
   • 追问：Read Committed（读已提交）会读到未提交数据吗？
   • 直接回答：正常可见性语义不会，但同一事务不同语句可以看到其他事务新提交的版本。
   • 追问：Repeatable Read（可重复读）能防所有业务并发异常吗？
   • 直接回答：不能，业务约束仍需条件写、锁、唯一约束或 Serializable（可串行化）并处理重试。
   • 追问：稳定 snapshot（快照）为何不宜保持数小时？
   • 直接回答：它会让旧版本持续可能可见，推迟空间回收与 freeze（冻结），形成膨胀和回卷风险。
   • 详情：锁与隔离

8. 问题：HOT（堆内更新）如何降低高频更新表的写放大？

   • 口述答案：HOT（堆内更新）的价值是当更新不改变任何索引键且原 page（页）有空间时，把新 tuple（元组）放在同一 page（页）并串成版本链，索引仍指向链入口，从而避免为每个二级索引写新项。它不等于原地覆盖，也不消除 heap（堆表）新版本、WAL（预写日志）和后续 VACUUM（空间回收）。以 Runner（执行器）任务表为例，100 万行、5 个二级索引，每分钟更新 10 万次 heartbeat_at；该列未被索引且页有预留时，若 80% 命中 HOT（堆内更新），只有约 2 万次进入普通索引维护路径。若新增心跳索引或页长期满载，命中率跌到 5%，约 9.5 万次更新需要维护多个索引，索引写入和清理量会急升。设计上先判断心跳是否真需要实时排序检索；若只是判断租约，可用更窄的专用访问路径、合理填充空间和批次控制。失败边界包括 expression index（表达式索引）或 partial index（部分索引）依赖该列、宽行导致同页容不下、长事务让链无法回收。验证要比较 HOT（堆内更新）命中、索引尺寸、WAL（预写日志）生成率和更新尾延迟，并在相同并发下确认查询收益没有被牺牲。 容量上还要观察版本链过长的反作用：一次索引定位后，heap（堆表）可能沿链检查多个版本，长 snapshot（快照）又推迟链修剪。若为了 HOT（堆内更新）降低填充密度，会增加初始 relation（关系）尺寸和扫描 page（页）数，因此参数不能只追求命中率。最终选择要让总写入、读取、缓存和清理成本在峰值下更低，并保留回退基线。 若命中率提升但业务写延迟没有下降，还要继续检查日志刷新、锁冲突和清理输入输出，避免把相关指标误当根因。
   • 追问：不修改普通索引列就一定命中吗？
   • 直接回答：不一定，还要检查表达式或部分索引依赖，并确保原 page（页）有足够空间。
   • 追问：HOT（堆内更新）会让旧版本消失吗？
   • 直接回答：不会，它只是优化版本链与索引维护，旧版本仍按 snapshot（快照）和清理边界保留。
   • 追问：如何判断优化有效？
   • 直接回答：在同负载下比较命中率、索引写入、WAL（预写日志）、page（页）增长和业务延迟。
   • 详情：HOT（堆内更新）与清理

9. 问题：请区分事务不可见、空间可复用和文件归还操作系统三个时点。

   • 口述答案：这是判断膨胀最重要的三段边界。第一，更新或删除事务提交后，旧 tuple（元组）对新的 snapshot（快照）可能已经不可见，但旧 snapshot（快照）仍可能读取它，所以物理版本不能马上移除。第二，当所有可能看见旧版本的事务结束后，VACUUM（空间回收）可以清理死 tuple（元组）和相关索引项，更新 FSM（空闲空间映射）与 VM（可见性映射），这时空间可被同一 relation（关系）后续写入复用。第三，普通 VACUUM（空间回收）通常不会搬移所有存活行来消除文件中间空洞，因此 relation（关系）文件未必缩小；只有截断尾部空闲或执行关系重写类维护，才可能把更多空间归还操作系统，而后者会带来锁、WAL（预写日志）、临时空间和副本压力。假设删除 800 GiB（吉字节）表中 300 GiB（吉字节）历史数据，业务查询立刻少了，但长事务仍可阻塞回收；清理完成后新写可复用 300 GiB（吉字节）中的大量空间，磁盘监控却仍显示原文件大小。项目决策应先问未来是否复用、是否真缺磁盘、维护窗口能否承受重写。验证分别看可见性、死版本与空闲空间、relation（关系）文件尺寸，不能用单一文件大小代表三个阶段。 对分区或归档场景，若业务确实按时间整段淘汰，优先评估能否通过数据生命周期设计避免大规模逐行删除；但对象删除、分区操作的锁、依赖和版本行为仍要现场核对。任何空间动作前都要确认备份恢复、WAL（预写日志）余量和副本状态，并设磁盘、锁等待与复制延迟回滚线，防止“释放空间”反而触发停机。
   • 追问：删除大量数据后磁盘不降是清理失败吗？
   • 直接回答：不一定，空间可能已在 relation（关系）内部可复用，只是尚未归还操作系统。
   • 追问：关系重写为什么风险高？
   • 直接回答：它可能需要额外锁、临时磁盘和大量 WAL（预写日志），还会加重副本追赶与回滚成本。
   • 追问：如何证明空间已可复用？
   • 直接回答：结合死版本下降、FSM（空闲空间映射）、后续写入不再扩文件和页级抽样交叉验证。
   • 详情：HOT（堆内更新）与清理

10. 问题：长事务为什么既造成膨胀又带来事务标识回卷风险？

• 口述答案：长事务的关键危害不是“运行时间长”本身，而是它可能长期持有旧 snapshot（快照）或事务标识边界。只要旧 snapshot（快照）仍可能看到历史 tuple（元组），VACUUM（空间回收）就不能回收相关版本；同时 freeze（冻结）推进也会受到全局最老边界约束，使老事务标识持续累积。假设事务 200 在 09:00 开始后保持三小时，期间每分钟更新 20 万行，旧 tuple（元组）平均 200 B（字节），仅旧版本理论就约 7.2 GB（吉字节），还未计索引与对齐。表尺寸上升、索引无效项增加、缓存工作集变大，最终查询和写入都受影响；若年龄逼近保护阈值，系统还要投入更激进的冻结工作，极端情况下影响可用性。第一类证据是最老事务开始时间、状态、snapshot（快照）与阻塞关系，第二类证据是死 tuple（元组）、relation（关系）增长和冻结年龄。止血前要确认事务归属与回滚代价，终止无业务价值的空闲事务，保护关键冻结任务和磁盘空间；长期修复连接池事务边界、游标分页和事务内远程调用。回归要模拟高峰更新，证明最老年龄在阈值内回落、autovacuum（自动清理）能追平且业务结果不受误终止影响。 监控不能只在接近保护线时告警，应同时看最老事务时长、各表年龄增长斜率、清理吞吐与每日更新量，提前判断“产生速度是否长期超过冻结速度”。对于业务必须保持的一致性导出，采用有界批次和可续跑水位，避免一个数小时事务持有全局旧视图；必要时迁到容量隔离的读取路径，但仍明确数据新鲜度和取消策略。
• 追问：所有长查询都会阻塞清理吗？
• 直接回答：要看它是否持有相关旧 snapshot（快照）和具体事务状态，不能只按查询耗时判断。
• 追问：能否直接终止最老事务？
• 直接回答：先确认业务副作用、回滚成本和责任人，再选择可回滚止血；关键事务不能盲杀。
• 追问：只提高 autovacuum（自动清理）频率有用吗？
• 直接回答：若旧 snapshot（快照）仍在，清理没有权限越过可见性边界，提高频率只会重复消耗资源。
• 详情：HOT（堆内更新）与清理

11. 问题：B-Tree（平衡树索引）、Hash（哈希索引）、GIN（通用倒排索引）、GiST（通用搜索树）和 BRIN（块范围索引）如何选？

• 口述答案：索引选择应从操作符、数据分布和返回路径出发，而不是从产品名出发。B-Tree（平衡树索引）维护有序键，能处理等值、范围和排序，是交易查询常用基础；Hash（哈希索引）按哈希桶服务纯等值，不支持范围和有序输出；GIN（通用倒排索引）把数组、文档或文本拆成多个键，按倒排项组合候选，适合包含和全文类查询，但更新、待合并结构与体积成本更高；GiST（通用搜索树）通过可扩展的包围和剪枝规则处理范围、空间或相似搜索，候选可能需要复核；BRIN（块范围索引）只存 page（页）范围摘要，索引很小，适合时间列与物理写入顺序高度相关的超大表，随机分布时会误命中大量块。跨境物流轨迹按时间追加，可比较 BRIN（块范围索引）与按运单号 B-Tree（平衡树索引）；商品标签包含可评估 GIN（通用倒排索引），但交易主键仍由关系约束负责。每个候选都要写清被加速查询、插入更新成本、page（页）访问、索引尺寸和淘汰条件。验证用代表性高低选择率查询观察实际计划、缓冲与写入基线，失败边界包括操作符类不匹配、物理相关性下降和索引收益被缓存假象夸大。 选择之后还要定义退场条件：查询频率下降、数据相关性改变、同功能索引重叠或写入延迟超过预算时，应重新评估而不是永久保留。索引创建本身也可能扫描大表、占临时空间并产生 WAL（预写日志），所以变更前要估峰值磁盘和副本追赶，变更后既比较查询收益，也观察插入更新、清理和恢复时间，形成完整生命周期证据。 最终文档会保存未选方案及原因，例如数据无物理相关性时拒绝 BRIN（块范围索引），让后续数据分布变化时能够重新评审，而不是重复从零争论。
• 追问：Hash（哈希索引）等值一定比 B-Tree（平衡树索引）快吗？
• 直接回答：不能保证，需结合缓存、数据规模、并发和写成本实测，B-Tree（平衡树索引）还提供更广访问能力。
• 追问：BRIN（块范围索引）会直接定位一行吗？
• 直接回答：通常先排除不可能的 page（页）范围，再回 heap（堆表）复核具体 tuple（元组）。
• 追问：GIN（通用倒排索引）适合高频更新状态列吗？
• 直接回答：不能仅因可查询就使用，应量化多键更新、合并与体积代价，并比较更简单的关系索引。
• 详情：索引家族

12. 问题：如何设计多列索引、partial index（部分索引）和 expression index（表达式索引）？

• 口述答案：设计起点是稳定查询形状，包括等值条件、范围、排序、投影和状态分布。多列 B-Tree（平衡树索引）的列顺序不是简单按单列选择率排序，而要看等值前缀能否缩小范围、后续列是否承担范围或排序，以及是否需要覆盖返回列。例如 WMS（仓储管理系统）查询某仓待拣单并按创建时间取前 100 条，可围绕 warehouse_id、status 与 created_at 的联合路径验证。若待执行任务只占全表 0.5%，partial index（部分索引）只覆盖待执行谓词，可显著降低体积；但查询条件必须能推出该谓词，状态迁移会写入或移出索引。expression index（表达式索引）保存规范化或计算表达式结果，查询表达式需匹配，函数语义和版本变化也要核对。覆盖列可减少取值回表，却增加索引宽度与更新成本，而且 index-only scan（仅索引扫描）仍依赖 VM（可见性映射）。失败边界是参数化条件无法匹配谓词、列相关性变化、索引重复和为了单次报表堆宽索引。评审时给出读收益、写放大、尺寸、约束范围和删除计划；回归用常见值、稀有值、状态迁移和写入高峰共同验证，避免只拿一条快查询作为结论。 对支付和库存表还要优先区分“访问路径索引”与“约束索引”：后者承担唯一性，即使读频率低也不能按慢查询收益随意删除。多个候选索引若前缀重叠，要检查能否合并而不破坏排序、谓词和约束；上线采用受控方式并记录构建进度、锁等待、WAL（预写日志）和副本水位，空间或延迟越线就暂停，而不是等磁盘耗尽再回滚。 查询上线后持续采样计划命中与写入增量，若实际工作负载偏离评审样本，就按预设淘汰条件撤销，而不是让试验索引永久留在交易表。
• 追问：多列索引是否把选择率最高列放最前？
• 直接回答：没有通用规则，要结合等值、范围、排序、操作符和查询前缀整体设计。
• 追问：partial index（部分索引）能保证全表唯一吗？
• 直接回答：只能约束谓词覆盖的子集，全表不变量需要覆盖全体的约束设计。
• 追问：覆盖更多列是否总能加速？
• 直接回答：可能减少取值回表，也会放大索引尺寸和更新；还要看 VM（可见性映射）是否允许跳过可见性检查。
• 详情：索引家族

13. 问题：为什么 1000 万行表有索引仍可能选择顺序扫描？

• 口述答案：cost-based optimizer（成本优化器）比较的是完整路径成本，不执行“有索引必须使用”的规则。假设 1000 万行出库单中 status='DONE' 有 920 万行，单列 B-Tree（平衡树索引）虽然能定位这些索引项，但仍要访问大量分散 heap（堆表）page（页），索引遍历加随机回表可能比顺序读取整表更贵；若表已经在缓存中，处理数百万 tuple（元组）的处理器成本仍存在。相反，warehouse_id=17 AND status='PENDING' 只有 8000 行，合适多列或 partial index（部分索引）会明显减少访问。优化器依据 statistics（统计信息）估算 selectivity（选择率），再用顺序 page（页）、随机 page（页）、处理器、并行和排序成本比较方案。失败常来自常见值分布过期、列之间强相关却被独立估算，或参数在热门与冷门仓库间差异巨大。排障用 EXPLAIN (ANALYZE, BUFFERS) 比较估算行和实际行、heap（堆表）块、循环与时间，再用磁盘或处理器作为第二证据。止血可限制失控查询或使用经验证改写，长期修正统计、索引或数据模型；关闭顺序扫描只能作为隔离对照，不能替代根因修复。 若查询带 ORDER BY 和小 LIMIT，能提供目标顺序的索引可能在不读取全部候选时胜出；若还要返回宽 TOAST（超大字段存储）列，回表和大值读取又会改变成本。面试时我会把“返回行比例、物理 page（页）数、所需顺序、行宽、冷热缓存”五项一起说清。回归还要观察计划对写入和缓存的外部影响，避免一条运营查询变快却让交易热点被驱逐。
• 追问：顺序扫描是否一定是坏计划？
• 直接回答：不是，返回比例高、小表或连续读取更便宜时，它可能是正确路径。
• 追问：强制索引能否长期解决？
• 直接回答：不能，它可能只适合当前参数和缓存，数据分布变化后反而更差。
• 追问：为什么第二次执行更快不能证明计划正确？
• 直接回答：第二次可能命中 shared buffers（共享缓冲区）或操作系统缓存，扫描量和并发代价并未减少。
• 详情：统计与扫描

14. 问题：bitmap scan（位图扫描）解决什么问题，何时会退化？

• 口述答案：bitmap scan（位图扫描）位于少量随机索引回表与大比例顺序扫描之间。它先从一个或多个索引取得 tuple（元组）物理位置，在内存中按 heap（堆表）page（页）聚合并可做交集或并集，再按 page（页）顺序批量回表复核条件；这样中等结果集不必按索引命中顺序反复随机访问同一 page（页）。例如跨境物流按国家、异常状态和时间段过滤，单个条件都不够稀疏，但组合后返回 30 万行，多个 B-Tree（平衡树索引）位图合并可能比新建一个超宽索引更合适。代价是位图占用工作内存；命中过多或内存不足时，位图可能退化为较粗的 page（页）级表示，回表要检查更多 tuple（元组），并且 bitmap scan（位图扫描）通常不能像有序 B-Tree（平衡树索引）扫描那样直接满足最终排序。统计低估还会让计划选择看似适中的位图，实际却访问大半张表。验证要看实际命中 page（页）、重新检查行、位图精确度、排序和临时读写，并与顺序扫描及联合索引方案比较。项目中它适合运营筛选，不应因为计划出现“索引”字样就忽略扫描总量；高峰下还要验证并发位图内存和对交易缓存的挤压。 位图路径还要关注并发：单条查询的内存可控，不代表几十条运营筛选同时执行仍安全；粗粒度位图会增加重新检查，排序又可能继续写临时文件。我的容量测试会固定相同数据快照，比较位图、联合索引和顺序扫描在三档选择率、两种缓存状态与峰值并发下的总 page（页）、处理器和尾延迟，然后按综合成本而非单次最快选择。 数据增长后还要重复同一矩阵，确认位图没有因返回比例上升从中间路径退化成高成本全表复核。
• 追问：位图能组合多个索引吗？
• 直接回答：可以按条件做交集或并集，但组合成本和回表量仍由数据分布决定。
• 追问：位图扫描会保持索引顺序吗？
• 直接回答：通常按 heap（堆表）page（页）组织访问，最终排序需求可能还需独立排序节点。
• 追问：何时考虑联合索引替代？
• 直接回答：查询形状稳定、组合高频且排序或覆盖收益明确时，用读写与空间基线比较后决定。
• 详情：统计与扫描

15. 问题：index-only scan（仅索引扫描）为何不保证零回表？

• 口述答案：仅索引扫描有两个独立前提：索引必须包含查询需要的过滤、排序和返回值，数据库还要能确认对应 heap（堆表）page（页）上的 tuple（元组）对当前 snapshot（快照）可见。索引项本身通常没有完整事务可见性状态，因此 VM（可见性映射）标记 page（页）全可见时才能安全跳过 heap（堆表）；page（页）被插入、更新或删除影响后，全可见标记会清除，直到 VACUUM（空间回收）确认再设置。于是同一个计划都叫 index-only scan（仅索引扫描），在静态历史表上可能几乎不回表，在高频状态表上却访问大量 heap（堆表）page（页）。例如异步导出历史记录按租户和完成时间查询，历史分区很稳定，覆盖索引收益高；Runner（执行器）心跳每秒更新，VM（可见性映射）频繁失效，即使覆盖心跳列也难取得相同收益，还会加重索引写入并破坏 HOT（堆内更新）。验证必须查看实际 heap（堆表）获取次数、全可见比例、清理进度和索引体积，不能只读计划节点名称。优化先减少无意义更新、让清理追上并收窄索引；失败边界是为了追求零回表加入太多列，最终写放大、缓存占用和构建空间超过读取收益。 这也说明 autovacuum（自动清理）是查询性能链的一部分：它不仅回收空间，还恢复部分 page（页）的全可见标记。若清理落后，覆盖索引的收益会逐渐下降；若盲目提高频率，又可能与前台输入输出争用。因此应按更新速度给清理资源、控制长事务，并用“全可见比例提升且 heap（堆表）获取下降”证明因果，而不是只看到清理进程运行。
• 追问：索引覆盖全部列为何还需可见性？
• 直接回答：MVCC（多版本并发控制）要判断该索引项对应版本是否对当前 snapshot（快照）可见。
• 追问：高频更新会怎样影响 VM（可见性映射）？
• 直接回答：相关 page（页）的全可见标记会失效，待后续 VACUUM（空间回收）重新确认。
• 追问：如何衡量真实收益？
• 直接回答：比较 heap（堆表）获取、缓冲 page（页）、索引尺寸、写入延迟和清理成本。
• 详情：统计与扫描

16. 问题：statistics（统计信息）偏差如何造成计划漂移，怎样闭环？

• 口述答案：优化器在真正执行前必须估算，所以 statistics（统计信息）质量直接决定计划基线。常见值、不同值数量、直方图、空值比例和物理相关性帮助估算 selectivity（选择率），但采样可能错过尖峰分布，两列强相关时独立估算还会把概率错误相乘。假设 5000 万行轨迹中，某国家异常件实际 80 万行，统计却估为 500 行，优化器可能用 Nested Loop（嵌套循环）和索引随机回表；冷缓存读取 12 万 page（页）耗时 9 秒，第二次热缓存 1.2 秒又掩盖问题。先保存事故计划、参数、估算行、实际行、缓冲与临时读写；再比较统计更新时间、数据装载、常见值和列相关性，必要时提高目标列统计精度或建立扩展统计，但参数效果要在目标版本验证。止血可以限制该报表并发、拆时间范围或使用已验证改写，不能直接在生产反复改全局成本参数。修复后用热门值、稀有值、边界日期和空值组成参数矩阵，在冷、热缓存及峰值并发下复测；还要模拟下一次批量导入和统计刷新，确认估算与实际长期接近，而不是只让事故参数变快。 对预编译或参数化查询还要注意：一次计划可能面对差异巨大的参数分布，热门国家与冷门国家的最佳路径不同。现场版本对通用计划、定制计划和统计字段的行为必须单独核对，不能凭记忆下结论。治理方案应优先让数据模型和查询边界稳定，必要的计划控制也要有期限、监控和退出标准，防止固定今天的最优成为明天的事故源。 监控会持续记录估算与实际行数比值，超过阈值时触发数据分布检查，而不是等尾延迟事故发生后才补统计。
• 追问：更新统计后一定会变快吗？
• 直接回答：不一定，它只改善估算输入；若缺少合适路径或查询本身读取量大，计划仍可能昂贵。
• 追问：缓存热后变快能否关闭事故？
• 直接回答：不能，扫描量、处理器和对其他热点的驱逐仍在，必须按冷、热和并发基线验证。
• 追问：全局修改随机读取成本是否合适？
• 直接回答：应先用真实存储和工作负载校准，避免为一条查询扭曲整个系统的计划选择。
• 详情：统计与扫描

17. 问题：Nested Loop（嵌套循环）、Hash Join（哈希连接）和 Merge Join（归并连接）如何判断？

• 口述答案：三种 Join（连接）没有固定排名，关键是连接条件、输入规模、索引、顺序和内存。Nested Loop（嵌套循环）让外表每行驱动内表访问，外表只有几百行且内表按键点查时很高效；若外表被估为 100 行、实际 100 万行，就会产生百万次内表扫描。Hash Join（哈希连接）适合等值连接，通常把较小侧放入哈希表，再扫描另一侧探测；构建侧超过工作内存时会分批写临时文件。Merge Join（归并连接）需要两侧按连接键有序，若索引已提供顺序可直接归并，否则先排序的成本和溢写必须计入。WMS（仓储管理系统）按 500 个待拣单点查明细可用 Nested Loop（嵌套循环）；跨境物流月度两张大表按运单号等值关联可能适合 Hash Join（哈希连接）；已按键有序的大批对账可评估 Merge Join（归并连接）。排障不只看顶层总耗时，要看每个节点实际行、循环次数、哈希批次、排序方法和临时块。失败边界通常是统计低估、连接顺序错误或工作内存被并发放大。修复后以真实数据分布和峰值并发回归，确保提升一条报表不会挤占支付、库存写入资源。 连接之外还要检查过滤落在何处：若本可在构建侧提前过滤的条件被晚执行，哈希表和中间结果会无谓变大；若外连接被错误改写，业务语义也可能改变。优化不能只追求算法名称，应先保持结果集合与空值语义，再调整连接顺序、索引和统计。回归以行数校验和关键业务聚合确认结果一致，避免性能修复悄悄漏掉运单或账务记录。 如果计划因参数变化在算法间切换，我会验证两条路径都不突破临时空间、循环次数和交易延迟门槛，并为极端参数设置查询范围保护。
• 追问：Nested Loop（嵌套循环）是否只适合小表？
• 直接回答：更准确地说是小外部结果驱动高效内表访问，底层表总大小不是唯一判断。
• 追问：Hash Join（哈希连接）能处理范围连接吗？
• 直接回答：核心路径依赖等值哈希匹配，范围条件通常需要其他算法或附加过滤。
• 追问：Merge Join（归并连接）为什么可能很慢？
• 直接回答：若两侧没有现成顺序，前置大排序和磁盘溢写可能超过归并本身成本。
• 详情：连接与溢写

18. 问题：异步导出为何容易因排序与磁盘溢写拖慢交易库？

• 口述答案：异步不等于没有资源成本，它只是把等待从用户请求移到后台。导出常包含大范围扫描、Join（连接）、排序和聚合，每个排序或哈希节点都可申请工作内存，并行工作者和多个任务并发会形成乘法放大。假设 8 个任务并发，每个计划有 2 个排序和 1 个 Hash Join（哈希连接），每节点 64 MiB（兆字节），理论工作内存已接近 1536 MiB（兆字节），还未计并行和其他会话；某排序输入 1200 万行、每项 48 B（字节），原始约 549 MiB（兆字节），必然走外部排序并产生临时读写。临时文件与数据 page（页）、WAL（预写日志）、checkpoint（检查点）共享磁盘，交易提交尾延迟随之升高。止血先暂停低优先级导出、限制并发与单任务时间范围，保留支付和库存连接池；用实际计划的临时块、排序方法与存储延迟、事务 fsync（强制刷盘）作为两类证据。长期采用基于稳定键的分段导出、缩小投影、提前过滤、预聚合或容量明确的只读副本，并标注副本水位。回归要同时运行峰值交易和导出，观察总内存、临时空间、磁盘延迟、复制落后与业务尾延迟，不能只比较单个导出完成时间。 导出一致性也要明确：若一个任务跨很久而要求同一 snapshot（快照），它会拖延版本回收；若分批提交，则必须记录上界水位，处理更新、删除与重跑，避免页间重复或遗漏。我的方案通常在任务创建时固化业务截止时间和稳定唯一键，每批独立事务导出并保存断点，完成后核对总行数与关键金额。这样既限制事务寿命，也让失败可续跑和结果口径可解释。 任务完成文件还要带数据水位、过滤条件和校验摘要，避免用户把不同时间口径的两个导出结果误判为数据库不一致。
• 追问：把工作内存调到 1 GiB（吉字节）能解决吗？
• 直接回答：可能减少单节点溢写，却会在多节点和多并发下造成全局内存压力，必须按乘法模型验证。
• 追问：切只读副本就没有风险吗？
• 直接回答：副本仍有磁盘和重放竞争，并可能数据陈旧，需设置水位、并发和回源边界。
• 追问：异步导出如何分页更稳？
• 直接回答：优先按稳定唯一键和明确上界分段，避免深偏移重复扫描，并记录断点和一致性口径。
• 详情：连接与溢写

19. 问题：锁与 MVCC（多版本并发控制）各自解决什么，为什么不能互相替代？

• 口述答案：MVCC（多版本并发控制）解决“当前 snapshot（快照）应看到哪个 tuple（元组）版本”，锁解决“并发动作能否同时修改同一资源或改变对象结构”。普通查询可读取更新前已提交版本，不必等待写事务完成，这是 MVCC（多版本并发控制）带来的读写并发；但两个事务同时更新同一库存行时，仍要通过行锁和冲突检测串行化修改。表级锁还协调查询、索引维护和架构变更，显式锁则可把业务判断与后续写入绑定在受保护范围内。假设库存事务甲锁商品一再请求商品二，事务乙顺序相反，就会形成等待环；数据库中止一方解除死锁，但应用必须幂等重试完整事务。另一方面，长 snapshot（快照）即使不阻塞写锁，也会让旧 tuple（元组）不能回收，所以“没有锁等待”不表示没有并发成本。项目设计中，扣库存使用条件更新或按稳定商品顺序取锁，支付使用唯一幂等流水，读取历史报表则尽量依赖 MVCC（多版本并发控制）而不扩大写锁范围。验证要同时看锁等待图、事务 snapshot（快照）、实际业务守恒和死版本增长；失败边界包括事务内远程调用、锁顺序不一致、架构变更等待和误把隔离级别当业务约束。 线上处置锁问题时，我会先保存等待者、持有者、锁模式、语句、事务年龄和业务请求，不先重启清空现场。止血优先取消低价值等待者或终止确认异常的持有者，并评估回滚时间；长期把锁对象顺序固化到代码评审规则，限制事务内批量大小和远程调用。回归用并发脚本同时验证死锁数、等待分位和库存守恒，而不是仅看错误日志消失。 发布架构变更前还会在影子环境验证所需表锁与持续时间，避免一个看似轻量的操作排在长事务后并阻塞全部新请求。
• 追问：普通查询完全不持锁吗？
• 直接回答：不能这样说，查询仍取得必要 relation（关系）级锁并可能受架构操作影响，只是通常不等待行更新完成。
• 追问：没有死锁日志就没有锁问题吗？
• 直接回答：不是，长时间单向等待不会成环，却仍可导致超时和资源堆积。
• 追问：条件更新为何有价值？
• 直接回答：把读取条件与写入裁决放入同一原子语句，避免应用先读后写之间的竞争窗口。
• 详情：锁与隔离

20. 问题：Serializable（可串行化）与 SSI（可串行化快照隔离）怎样防止写偏差？

• 口述答案：写偏差发生在两个事务读取同一约束集合，却分别更新不同记录，行锁可能不直接冲突，最终组合违反业务规则。Serializable（可串行化）要求已提交结果等价于某种串行执行顺序；PostgreSQL（关系型数据库）的 SSI（可串行化快照隔离）不是把所有查询都排队，而是让事务按 snapshot（快照）并发读取，同时跟踪读写依赖，当依赖形成可能无法串行化的危险结构时中止一个事务。比如仓库要求至少保留一名值班审核员，甲、乙都读到两人在线，分别把不同人员设为离线；普通稳定快照下两行更新不冲突，却可能得到零人。SSI（可串行化快照隔离）可识别依赖并让一方序列化失败。应用责任是从完整事务边界幂等重试，不能只重放最后一条更新，也不能在事务中先发送不可撤回外部消息。它的代价是依赖跟踪、失败重试和长事务增加冲突概率，因此简单库存计数可能更适合条件更新与约束，复杂跨行决策再评估 Serializable（可串行化）。验证要并发复现业务不变量、统计中止率并确认重试后结果正确；失败边界是无限重试、重试风暴和外部副作用重复，需有退避、上限和人工处置。 选择 Serializable（可串行化）前还要估算事务读集合和持续时间，读很多行、保持很久的事务会增加依赖跟踪与重试概率。重试策略采用指数退避、次数上限和业务截止时间，并记录冲突业务键；若同一热点持续失败，应串行化该键或改写不变量，而不是无限自动重试。回归除了成功率，还要确认失败事务没有留下消息、文件或第三方调用等不可回滚副作用。
• 追问：SSI（可串行化快照隔离）等于严格两阶段锁吗？
• 直接回答：不等于，它保留快照并发并通过读写依赖检测中止危险事务，不是把所有读都变成阻塞锁。
• 追问：序列化失败表示数据库故障吗？
• 直接回答：通常是并发正确性保护的预期结果，应用应按设计重试完整幂等事务。
• 追问：为何不把所有事务都设为 Serializable（可串行化）？
• 直接回答：要权衡冲突、中止、重试复杂度和工作负载，能用更直接约束表达的不变量不必一律升级。
• 详情：锁与隔离

21. 问题：如何量化五个二级索引给高频更新带来的写放大？

• 口述答案：我会按即时写、延迟维护和复制三层量化。即时层中，一次更新先创建 heap（堆表）新 tuple（元组）并让旧版本失效；若 HOT（堆内更新）条件不成立，每个受影响二级索引还要写新索引项。假设支付状态表每秒更新 5000 行，tuple（元组）平均 220 B（字节），5 个索引项平均 40 B（字节），忽略页头与分裂时，净新内容已经约 5000*(220+5*40)=2.0 MB/s（兆字节每秒）。随后 WAL（预写日志）还要描述变化，checkpoint（检查点）周期内可能产生 full-page write（整页写），数据 page（页）异步刷盘并传给两个副本；延迟层则由 VACUUM（空间回收）扫描 heap（堆表）与索引、清除死项和更新映射。实际放大还包括页分裂、对齐、缓存淘汰、归档与副本重放，不能拿 2.0 MB/s（兆字节每秒）当最终值。评审每个索引时列出命中查询、约束作用、扫描节省、尺寸、更新依赖和删除条件；低收益重复索引应合并或下线。验证在同等流量下比较 WAL（预写日志）生成率、page（页）写入、索引尺寸、HOT（堆内更新）命中、清理耗时与业务尾延迟，并覆盖索引创建和副本追赶空间峰值。 对索引变更还要计算构建峰值：800 GiB（吉字节）heap（堆表）、260 GiB（吉字节）目标索引、180 GiB（吉字节）临时排序和120 GiB（吉字节）额外日志，新增需求可能超过 560 GiB（吉字节），不能用稳态余量批准。上线前应预演取消、失败清理和副本追赶，确认空间告警与回滚动作真实可执行；否则查询收益再高也不具备实施条件。 容量报告同时给出稳态、日峰值、单副本故障追赶和一次维护重写四种水位，任何一种越线都不批准新增索引。
• 追问：未修改索引列也会写五个索引吗？
• 直接回答：若满足 HOT（堆内更新）可避免相应新索引项；否则跨页新版本可能需要维护索引，需以实际指标确认。
• 追问：唯一索引只有查询收益吗？
• 直接回答：不是，它还承担业务约束，评审不能只按读延迟删除，但仍要避免重复表达同一约束。
• 追问：副本数量如何影响？
• 直接回答：主库生成日志不简单按副本数复制写一遍，但网络、接收、持久化、重放和恢复容量会随副本增加。
• 详情：写放大与容量

22. 问题：检查点尖峰和 WAL（预写日志）暴涨如何区分生成过快与保留过久？

• 口述答案：先把 WAL（预写日志）问题拆成生成、消费和回收。生成过快常伴随事务量、批量更新、索引维护或 full-page write（整页写）增加；检查点过密会让更多 page（页）在新周期首次修改时记录整页镜像，并推动脏页集中写出。保留过久则可能是归档失败、复制槽消费者停滞或副本长期落后，即使当前写入正常，旧日志也不能回收。第一类证据看单位时间 WAL（预写日志）字节、记录类型、检查点开始结束、脏页写出与事务量；第二类证据看归档成功率、各副本发送/接收/刷新/重放 LSN（日志序列号）、复制槽保留位置和磁盘延迟。假设主库生成 80 MiB/s（兆字节每秒），副本只能重放 50 MiB/s（兆字节每秒），10 分钟就积累约 18 GiB（吉字节）位置差；若归档同时失败，磁盘下降会更快。止血按责任动作：限制异常批次、平滑检查点、恢复归档或处理停滞消费者，绝不能直接删除受管理日志。长期修复容量、槽生命周期和告警阈值；回归要覆盖高峰写入、一次副本中断与恢复，证明日志可回收、恢复链连续且前台提交延迟没有周期尖峰。 若磁盘已经接近红线，处置顺序仍以保持恢复链为前提：先停止非关键大写入，确认可安全释放的临时文件和失败任务产物，再恢复归档或让副本追赶；任何复制槽删除都要由业务责任人确认消费者不再需要该位置。恢复后从最近基础备份和归档日志做隔离演练，证明保留策略既不会无限占盘，也没有切断恢复所需连续区间。 告警至少同时覆盖生成速率、剩余可用时长、归档连续失败次数和最老保留位置责任人，确保值班人员能在磁盘耗尽前选择正确动作。
• 追问：磁盘中 WAL（预写日志）多就是写入暴涨吗？
• 直接回答：不一定，也可能是归档、复制槽或副本阻止回收，必须比较生成率和最老保留责任。
• 追问：能否删除最旧日志先救磁盘？
• 直接回答：不能盲删，这可能破坏崩溃恢复、归档连续性与副本追赶，导致必须重建。
• 追问：检查点调稀就一定好？
• 直接回答：会降低部分整页镜像频率，却可能增加恢复时间和日志保留，需要同时满足恢复目标与空间预算。
• 详情：日志与恢复

23. 问题：缓存命中率很高但查询仍慢，怎样避免缓存误判？

• 口述答案：缓存命中率回答“请求的 page（页）是否已在某层内存”，不回答“为什么请求这么多 page（页）”或“处理这些 page（页）是否便宜”。一条全表扫描可以从 shared buffers（共享缓冲区）命中 100 万个 page（页），命中率接近 100%，仍消耗处理器和内存带宽，并把支付与库存热点 page（页）驱逐；排序、Hash Join（哈希连接）、锁等待和客户端读取慢也不体现在命中率里。相反，命中率下降可能只是批量报表首次读取冷数据，物理存储延迟仍在目标内，不等于内存不足。排障先用 EXPLAIN (ANALYZE, BUFFERS) 看每节点实际行、循环、命中、读取、临时块和时间，再用操作系统物理读延迟、处理器、进程等待或应用调用链做第二证据。还要区分数据库缓存、操作系统缓存和存储设备缓存，第二次执行更快可能只是缓存预热。止血可取消失控扫描、限制报表并发并保护交易连接；长期减少扫描范围、修正索引与统计、隔离批任务。回归分别在冷、热缓存和混合高峰下比较总 page（页）、尾延迟与热点命中，目标是减少无效工作而不是追求某个全局百分比。 对缓存优化的业务结论还要落到优先级：支付幂等流水、库存热点页和调度租约属于高复用交易工作集，应避免被一次历史扫描挤出；跨境物流全量分析可以限流、分段或迁往专用读模型。调整后若全局命中率下降但交易尾延迟和总物理读反而更稳，也可能是更好的结果，因此验收指标必须围绕工作负载而不是追求漂亮百分比。 回归报告会列出交易查询与报表各自的 page（页）访问和尾延迟，防止总指标改善掩盖关键链路退化。
• 追问：命中率 99% 是否表示内存配置合理？
• 直接回答：不能单独判断，还要看访问 page（页）总量、工作集复用、物理读延迟和热点是否被驱逐。
• 追问：为什么全表扫描会污染缓存？
• 直接回答：它访问大量低复用 page（页），可能占用缓存与带宽并挤出高频交易数据，具体策略需现场观测。
• 追问：增加内存何时有效？
• 直接回答：当高复用工作集确实超过可用缓存且扫描量合理时才可能有效，并需验证并发与操作系统余量。
• 详情：写放大与容量

24. 问题：表和索引膨胀、autovacuum（自动清理）落后时如何处理？

• 口述答案：先区分正常业务增长、死版本暂存和长期不可复用膨胀。第一类证据是活行、死 tuple（元组）、relation（关系）及索引尺寸、页密度和 autovacuum（自动清理）进度；第二类证据是更新删除速率、长事务、锁阻塞、磁盘与处理器资源。若尺寸随活数据线性增长是容量问题；若业务行稳定而死版本、索引和文件持续增大，则检查最老 snapshot（快照）、清理是否反复被取消、单表阈值是否不适配高更新、HOT（堆内更新）是否因页满或索引设计失效。止血先保留磁盘余量、限制无价值批量更新、终止确认无用的长事务并给关键清理资源，不能在未知锁和副本压力时直接重建所有索引。长期修复事务边界、填充空间、更新列索引、按表清理参数和任务调度；必要的关系重写要预算临时空间、WAL（预写日志）、锁和副本追赶。回归看峰值后死版本能否在目标窗口下降、文件增长斜率是否稳定、新写是否复用空间、查询与写入尾延迟是否恢复。即便重建后文件变小，也要观察数周是否复发，才能证明根因解决。 索引膨胀与 heap（堆表）膨胀也要分别度量：HOT（堆内更新）失败会增加索引旧项，低选择率索引即使不大也可能没有价值；清理后 heap（堆表）空间可复用，不代表索引结构已恢复理想密度。维护计划按对象选择清理、重建或保留，并在任何重写前计算临时空间、锁窗口和副本影响，避免“一键维护”把局部问题升级为全库故障。 维护完成后还要重新采集查询计划，因为对象尺寸和统计变化可能改变 cost-based optimizer（成本优化器）的路径，空间恢复不代表性能自动稳定。
• 追问：autovacuum（自动清理）在运行为何仍膨胀？
• 直接回答：它可能受旧 snapshot（快照）、锁、资源、阈值或产生速度限制，进程存在不等于能回收目标版本。
• 追问：重建索引是第一步吗？
• 直接回答：通常不是，先找版本产生和无法回收的原因，否则重建后仍会复发并制造额外空间压力。
• 追问：如何证明空间开始复用？
• 直接回答：观察死版本下降、后续写入时 relation（关系）不再同比扩张，并用页密度或空闲空间抽样交叉。
• 详情：维护排障

25. 问题：请给出一次 PostgreSQL（关系型数据库）综合故障的排障闭环。

• 口述答案：我按“影响、现场、竞争假设、两类证据、止血、修复、回归”执行。假设晚高峰支付接口 P99（99 分位响应时间）从 80 ms（毫秒）升到 2 s（秒），WAL（预写日志）磁盘快速下降且副本落后。先固定起止时间、实例、发布、错误率和资损风险，暂停低优先级异步导出，保留最小写入能力。数据库侧保存活动事务、锁等待、实际计划、检查点、WAL（预写日志）生成与各 LSN（日志序列号）水位；主机侧保存磁盘延迟、吞吐、处理器和临时文件；应用侧对齐导出任务与支付耗时。竞争假设至少包括检查点刷页尖峰、导出排序溢写、异常批量更新生成日志和副本槽保留。若证据显示导出产生大量临时写，同时检查点集中刷页，停止导出后存储延迟和支付 fsync（强制刷盘）同步恢复，只能证明止血有效，还要修导出并发、时间范围和检查点节奏。若日志仍不回收，再处理归档或停滞槽。回归同时运行峰值支付、受控导出和一次副本断连，验证交易不变量、尾延迟、磁盘余量、日志回收和追平时间。任何直接重启、删日志或只看缓存命中率的做法都会破坏现场或扩大恢复风险。 事故记录还要明确每个断言的反证条件：若停止导出后临时写下降但 fsync（强制刷盘）仍高，则继续验证检查点或存储；若主库日志生成恢复而磁盘仍下降，则转向归档和保留责任。最终报告保留原始时间线、执行计划、参数变更、回滚阈值和未排除风险，避免把相关指标拼成唯一故事。下一次演练复用同一采样和告警，才能验证组织真正具备恢复能力。 复盘动作必须有负责人、完成日期和可自动验证指标，下一次相同告警若仍只能人工猜测，就说明修复尚未真正闭环。
• 追问：接口恢复是否证明导出是唯一根因？
• 直接回答：不证明，停止导出可能同时缓解多种资源竞争，仍需节点计划和存储时间线交叉验证。
• 追问：为什么先保护支付写入？
• 直接回答：支付是权威资金链，报表和导出可降级；优先级必须按业务不变量而非任务先后决定。
• 追问：回归为何要注入副本断连？
• 直接回答：验证日志保留、磁盘容量和恢复追赶在故障窗口仍满足目标，而非只测稳态。
• 详情：维护排障

26. 问题：如何用 PostgreSQL（关系型数据库）设计 WMS（仓储管理系统）库存防超卖？

• 口述答案：库存不变量是可售、预占、释放和出库之间守恒，最终裁决必须在交易主库完成。核心表以仓库、SKU（库存量单位）和批次形成稳定业务键，扣减使用带条件的原子更新或按稳定顺序取行锁，例如只在可售数量足够时减少并增加预占；订单请求带幂等键并由唯一约束防重复。事务同时写库存当前态和不可变流水，提交成功只表示本地权威事实成立，后续搜索、看板和分析通过提交后事件投影。MVCC（多版本并发控制）让普通查询读取已提交版本，但不能用先读数量、应用内减一、再无条件写回替代并发裁决。热点 SKU（库存量单位）要单独压测锁等待、死锁和更新 page（页），通过批次、分仓、削峰或更细业务键治理，而不是把库存随机分库后依赖跨库补偿。若提交响应未知，按订单幂等键回权威流水确认；若搜索显示有货而主库不足，以主库拒绝为准。验证覆盖 100 个并发请求争抢 10 件库存、取消释放、重复消息、事务超时和副本延迟，逐笔核对 初始+入库-预占+释放-出库=期末，再检查死锁重试、WAL（预写日志）、清理和投影水位，证明正确性与容量都成立。 数据模型还需处理跨仓调拨：源仓减少与目标仓增加要么处于同一可控事务边界，要么通过明确状态机和在途库存守恒拆分，不能让搜索或缓存双写充当补偿。热点治理也不能牺牲审计，任何聚合扣减都应展开为可追溯业务流水。恢复演练从流水重建指定仓库库存，与当前态逐项比较，只有差异为零且重复事件不改变结果，才能证明方案可恢复。 面向运营的库存看板即使允许秒级滞后，也要展示数据水位并在提交入口重新校验，不能让展示承诺越过交易裁决。
• 追问：搜索索引能否直接扣库存？
• 直接回答：不能，索引存在可见延迟、重建和重复投影窗口，不承担库存事务与守恒约束。
• 追问：行锁是否一定会导致低吞吐？
• 直接回答：不一定，冲突由热点分布和事务时长决定；短事务、稳定顺序和合理业务键可保持可控吞吐。
• 追问：库存读副本显示 10 能否承诺下单？
• 直接回答：只能用于展示，提交时仍由权威节点基于当前状态原子裁决。
• 详情：项目边界

27. 问题：支付资金一致性为什么适合以 PostgreSQL（关系型数据库）为权威源？

• 口述答案：支付需要唯一业务键、明确状态机、金额守恒、事务原子性、审计流水和可恢复证据，这些约束适合放在 PostgreSQL（关系型数据库）交易边界中。每个支付动作以订单号、渠道和动作类型形成幂等键，事务内先校验合法状态迁移，再写资金流水、支付状态和待发布事件；唯一约束阻止重复动作，条件更新阻止旧状态覆盖新状态。WAL（预写日志）持久化让已确认事务可在崩溃后重放，但数据库提交不能自动覆盖渠道扣款、消息发布和用户响应，所以还要有 Outbox（发件箱）、渠道查单、重试与日终对账。响应超时时先查权威流水，读副本或搜索判空不能作为未支付结论。分析副本可做商户报表和风险聚合，搜索索引可查订单，但都只消费版本化事件；若投影落后，展示可标注更新中，资金事实不能反向修改。故障时先冻结可能重复扣款的新动作，保留幂等键、LSN（日志序列号）、渠道流水和消息水位；恢复后对总账、明细和渠道金额三方对账。回归注入提交后丢响应、重复回调、消息重复、渠道成功数据库超时和副本延迟，证明每笔资金最多记一次且任何未知状态最终可查清。 容量与性能同样服务正确性：支付状态高频更新若索引过多，WAL（预写日志）、清理和副本延迟会放大未知窗口；长对账查询若持有旧 snapshot（快照），又会推迟回收。因此交易表只保留约束和高价值访问路径，对账采用有界批次或隔离读模型，但每个汇总数字都能追溯到权威流水。告警不仅看接口错误，还看未知状态年龄、幂等冲突和对账差额。 恢复演练还要从基础备份和 WAL（预写日志）重建指定时间点账务，逐笔重算余额，证明恢复后的金额与原审计链一致。
• 追问：数据库事务成功等于渠道扣款成功吗？
• 直接回答：不等于，渠道是外部副作用，需要查单、幂等和对账；本地事务只保证自身边界。
• 追问：为何保留不可变流水？
• 直接回答：当前状态只能给结论，流水提供状态演进、审计、对账和恢复重建证据。
• 追问：分析副本金额一致就能关闭差异吗？
• 直接回答：不能，分析副本可能延迟或漏投影，最终要回权威流水与渠道记录逐级核对。
• 详情：项目边界

28. 问题：跨境物流复杂查询如何在交易主库与搜索、分析系统间分工？

• 口述答案：先定义权威事实：运单、轨迹事件、来源、事件时间、写入时间和修正记录必须可追溯保存在交易或事件权威源中。客服按单号、国家、承运商和时间范围的精确组合查询，可以由 PostgreSQL（关系型数据库）的 B-Tree（平衡树索引）、partial index（部分索引）或时间相关 BRIN（块范围索引）承担；全文地址、异常描述和多字段相关性检索投影到搜索系统；跨亿级历史的时效聚合和趋势分析投影到分析系统。投影事件携带运单业务键、版本、删除与来源水位，消费者幂等应用，不能把搜索排序结果当轨迹事实。主库中的复杂运营查询也要控制范围：统计偏差可能让索引扫描退化，异步导出会排序溢写并争用 checkpoint（检查点）磁盘，因此高峰限并发、按稳定键分段，必要时使用有水位的只读副本。若搜索或分析落后，客服可回源查单条权威轨迹并提示聚合更新中；交易状态更新仍只写权威源。验证用同一批运单比较主库事件数、最后状态、删除、迟到修正与派生水位，再注入重复、乱序、索引重建和副本延迟，确保查询降级不改变原始事实。 物理设计还要随访问模式演进：近期轨迹按运单和时间高频点查，历史数据更多用于聚合，可通过有界分区、归档和派生系统降低主库工作集；但迁移必须先全量快照再按事件水位追增量，校验行数、最后状态、删除和业务聚合。切换失败时读路径可回旧系统，写入仍以唯一权威源为准，避免双写分叉后无法判定哪侧可信。 对迟到修正必须保留原事件和修正版本，派生系统重算最后状态时按业务规则处理，不能直接覆盖历史而失去争议证据。
• 追问：所有轨迹都长期留在主交易表吗？
• 直接回答：需按审计、恢复和查询需求设计分区与归档，但权威事实必须有可验证保留或恢复路径。
• 追问：BRIN（块范围索引）适合运单号吗？
• 直接回答：若运单号与物理顺序无相关性，摘要效果可能差；时间追加列通常更符合其前提。
• 追问：搜索结果与主库状态不一致怎么办？
• 直接回答：展示标注水位并回源权威记录，修复投影后重放校验，禁止搜索反向覆盖主库。
• 详情：项目边界

29. 问题：异步任务和 Runner（执行器）调度怎样避免旧副本造成重复执行？

• 口述答案：任务领取、租约和成功状态必须在权威调度表中原子裁决，搜索索引、缓存和只读副本只用于观察。任务表保存业务幂等键、状态、租约持有者、租约到期、尝试次数、版本和最终结果；Runner（执行器）领取时用条件更新把“待执行且租约可用”改为“运行中并写持有者”，受影响行数为一才获得执行权。心跳更新频繁，要避免为每个展示需求建立索引破坏 HOT（堆内更新）；高频时间列若被索引会让五个二级索引写放大和 VACUUM（空间回收）压力上升。执行外部副作用前还要使用业务幂等键，租约到期后的重试不能重复发货或扣款。查询副本可能尚未重放最新租约，若根据副本“待执行”再次领取，就会重复执行；因此副本只能做列表和报表，并标注 LSN（日志序列号）或时间水位。异步导出同样要限制排序与临时文件，避免调度后台拖慢交易提交。验证并发启动多个 Runner（执行器）、注入进程崩溃、心跳延迟、副本落后和响应未知，确认同一时刻只有一个有效租约、最终副作用幂等、超时任务可安全接管，并观察锁等待、HOT（堆内更新）、死版本与清理追平。 对僵尸执行者还要设置隔离令牌或版本号：旧 Runner（执行器）即使网络恢复，也不能以过期租约提交最终结果；权威表条件更新必须同时匹配任务标识、持有者和租约版本。监控按任务类型记录领取冲突、租约过期、重复副作用拦截和最长运行时间。恢复积压时分优先级放量，先保障支付补偿与库存任务，再恢复报表，避免所有任务同时争锁和写日志。 最终验收还会把任务状态表与外部副作用按幂等键对账，积压清空但对账不平仍视为未恢复。
• 追问：唯一约束能完全防重复执行吗？
• 直接回答：它能防重复任务记录或结果键，但租约并发和外部副作用仍需条件更新与幂等协议。
• 追问：为何不把心跳写缓存？
• 直接回答：可用缓存承载辅助存活信号，但任务所有权和最终状态仍需权威、可审计且可恢复的裁决。
• 追问：租约到期就能立即接管吗？
• 直接回答：还要考虑时钟、原执行者隔离和副作用幂等，接管必须通过权威条件更新获得新版本。
• 详情：项目边界

30. 问题：请总结 PostgreSQL（关系型数据库）的设计思想、适用边界与版本核对方法。

• 口述答案：我用五个取舍总结。第一，heap（堆表）与索引分离，让同一业务事实拥有多种访问路径，但每个索引都增加写入、缓存、清理和恢复成本。第二，MVCC（多版本并发控制）用多版本换取普通读写并发，把阻塞成本转化为死 tuple（元组）、VACUUM（空间回收）、freeze（冻结）和长事务治理。第三，WAL（预写日志）把逐事务随机数据 page（页）持久化转成顺序恢复日志，缩短提交关键路径，但随机页写、检查点和恢复容量没有消失。第四，cost-based optimizer（成本优化器）基于 statistics（统计信息）、selectivity（选择率）和缓存成本选计划，不遵循“有索引必用”的规则。第五，删除后不可见、空间可复用和文件缩小是三个时点。适用边界上，支付、库存、运单事实和 Runner（执行器）租约需要约束、事务、幂等和审计，应保留为权威源；全文搜索、大范围分析和看板投影到专用系统，并维护版本、水位、校验、回源和重建。项目版本登记“待现场核对”，默认值、监控字段、锁细节和参数行为必须在目标环境对照官方手册与最小实验，记录服务器、存储、复制、扩展、配置、核对日期和回退条件。最终通过崩溃恢复、并发不变量、计划矩阵与故障注入证明结论，而不是背版本号。 现场核对不只抄版本号，还要把结论和证据绑定：例如提交语义记录配置与断连实验，索引能力记录操作符与实际计划，清理阈值记录表级设置与年龄变化，复制可见记录各阶段 LSN（日志序列号）。升级前重复最小实验和恢复演练，若行为或默认值变化就更新方案与回退线。这样知识材料提供稳定因果模型，生产决策则由可复核的当前环境事实负责。
• 追问：跨版本稳定机制能否直接用于方案？
• 直接回答：可作为模型起点，但实现细节、默认值和边界仍需目标环境官方手册与实验确认。
• 追问：数据量大是否意味着不再适合交易主库？
• 直接回答：不能只看体量，应拆不变量、访问形状、增长、恢复目标和团队能力，再决定分区、归档或派生系统。
• 追问：如何证明搜索和分析没有越权？
• 直接回答：所有交易命令只在权威源裁决，派生侧只消费版本事件，出现差异时回源并可从权威日志重建。
• 详情：设计思想与版本卡

3. 复习与验收清单

• 能从 cluster（集群实例）连续讲到 tuple（元组），并区分主数据、FSM（空闲空间映射）、VM（可见性映射）与 TOAST（超大字段存储）。
• 能按“解析、执行、shared buffers（共享缓冲区）、WAL buffer（预写日志缓冲区）、fsync（强制刷盘）、checkpoint（检查点）、副本重放”复述写路径。
• 能用事务 100 至 160 演绎 xmin、xmax、snapshot（快照）、更新、回滚、删除和清理边界。
• 能比较五类索引、四类扫描、三种 Join（连接），并用实际计划、缓冲和临时文件解释选择。
• 能区分行锁、表锁、MVCC（多版本并发控制）、三档隔离和 SSI（可串行化快照隔离），说明完整事务重试责任。
• 能对九类维护事故给出现象、两类证据、止血、修复和回归，并拒绝删日志、盲目重启和单指标定性。
• 能说明支付、库存、跨境物流与 Runner（执行器）的权威源和派生读模型边界，交易不变量绝不交给搜索或分析副本。
• 版本仍为“待现场核对”；版本敏感行为一律以目标环境官方手册和实验为准。