# 1. PostgreSQL 32 位事务 ID（XID）为什么存在回卷风险（以 2^31 为模的环形比较，新旧会颠倒）？冻结（freeze，置为 FrozenTransactionId）如何让老版本“永久可见”从而安全回收 XID？ A XID 是 64 位，不会回卷 B XID 以 2^31 为模环形比较，冻结置为 FrozenTransactionId 使老版本永久可见 ✓ 正确答案 C 冻结会让老版本不可见 D 冻结与 VACUUM 无关
# 2. autovacuum_freeze_max_age 与 anti-wraparound VACUUM 的触发条件是什么？为什么防回卷 VACUUM 不能被取消（包括 pg_cancel_backend），只能等待或降低 IO 影响？ A 防回卷 VACUUM 可以被 pg_cancel_backend 取消 B 防回卷 VACUUM 因回卷风险不可取消，只能等待或降低 IO 影响 ✓ 正确答案 C autovacuum_freeze_max_age 与回卷无关 D 回卷风险不会导致数据库不可用
# 3. 如何通过 pg_database 的 age(datfrozenxid)、mxid_age(datminmxid) 监控 XID 消耗？接近 2 亿时应采取哪些应急与根治措施？ A age 只反映已提交事务数 B age(datfrozenxid) 监控最老未冻结事务年龄，接近阈值需执行 VACUUM FREEZE ✓ 正确答案 C age 接近 20 亿仍可正常写入 D 长事务不会影响 age
# 4. pg_xact（原 CLOG，提交状态日志）与 XID 可见性判定是什么关系？它的截断（truncate）如何与冻结进度协同？ A CLOG 永不截断 B CLOG 与可见性无关 C 冻结会增加 CLOG 大小 D pg_xact 记录事务提交状态供可见性判定，冻结后旧事务的 CLOG 可被截断回收 ✓ 正确答案
# 5. PostgreSQL 12+ 的仅索引冻结（index-only freezing）与 PG 14 的自底向上索引删除（bottom-up deletion）如何减少索引膨胀与冻结开销？ A bottom-up deletion 只处理表数据 B 两者都增加索引膨胀 C index-only freezing 用 VM 减少表页读取，bottom-up deletion 清理冗余索引项控制膨胀 ✓ 正确答案 D 这些优化与 VACUUM 无关
# 6. VACUUM FREEZE 如何设置元组的 hint bits 与 xmin 冻结标志？它与全页写（full-page write）、WAL 量的关系是什么？ A 冻结设置 xmin 冻结标志与 hint bits，修改页会触发全页写从而增加 WAL 量 ✓ 正确答案 B 冻结不产生任何 WAL C 全页写与冻结无关 D hint bits 会降低可见性判定效率
# 7. 复制槽导致 WAL 堆积（pg_wal 膨胀）的机理、监控与清理（restart_lsn） A 复制槽与 WAL 保留无关 B 复制槽根据 restart_lsn 保留 WAL，下游不消费会致 pg_wal 膨胀，需监控落后量 ✓ 正确答案 C 下游不消费会自动截断 WAL D 复制槽无法删除
# 8. 数据库因 XID 耗尽拒绝服务时如何抢救（单用户模式 vacuum freeze）？pg_resetwal 的风险与适用边界是什么？ A XID 耗尽无法抢救 B 单用户模式可绕过 XID 限制执行 vacuum freeze，pg_resetwal 是高风险的最后手段 ✓ 正确答案 C pg_resetwal 无风险，可随意使用 D 单用户模式无法执行 VACUUM
# 9. PostgreSQL 的多进程模型（每个连接 fork 一个 backend 进程）为什么使高并发短连接代价高昂？与 MySQL 的线程模型相比在内存与切换开销上有何差异？ A PG 每连接一个进程，高并发短连接开销大，常需连接池；MySQL 线程模型更轻量 ✓ 正确答案 B 两者都是线程模型 C PG 进程模型连接开销小 D MySQL 连接开销大于 PG
# 10. max_connections 设置要考虑哪些每连接内存开销（work_mem、temp_buffers 均为会话级）？为什么不宜简单调到数千而应前置连接池？ A work_mem 是共享内存，与连接数无关 B work_mem 等会话级内存按连接分配，大量连接会耗尽内存，应前置连接池 ✓ 正确答案 C max_connections 可随意调到数千而无内存风险 D 连接池会增加后端连接数
# 11. PgBouncer 的 pool_size、reserve_pool、server_lifetime、max_client_conn 参数如何影响后端连接数与复用效率？ A pool_size 决定前端客户端数 B pool_size 控制后端连接数，reserve_pool 应对峰值，server_lifetime 轮换连接 ✓ 正确答案 C server_lifetime 让连接永不轮换 D reserve_pool 减少后端连接
# 12. PgBouncer 如何通过 auth_user + SCRAM 透传完成对后端的认证（避免在连接池保存明文密码）？ A SCRAM 无法在 PgBouncer 使用 B PgBouncer 必须保存明文密码 C auth_user 与认证无关 D auth_user 从后端查询密码哈希，配合 SCRAM 透传避免在连接池保存明文密码 ✓ 正确答案
# 13. 如何通过 SHOW POOLS / SHOW STATS（cl_waiting、maxwait、server_active_conn）诊断连接池耗尽？ A cl_waiting 表示后端连接空闲数 B cl_waiting 与 maxwait 反映客户端等待，server_active_conn 满说明后端连接被占 ✓ 正确答案 C maxwait 是后端连接数 D SHOW POOLS 无法查看等待情况
# 14. 主从切换后如何防止连接风暴（thundering herd），池预热、客户端指数退避、代理层熔断？ A 所有客户端同时重连是最优策略 B 连接风暴无法预防 C 池预热、客户端指数退避、代理熔断可分散重连压力保护新主库 ✓ 正确答案 D 指数退避会让所有客户端同时重连
# 15. 逻辑解码（Logical Decoding）的插件，pgoutput、wal2json、test_decoding？ A pgoutput 用于内部复制，wal2json 输出 JSON 供外部消费，test_decoding 用于测试 ✓ 正确答案 B 三者输出完全相同的格式 C pgoutput 输出 JSON 格式 D wal2json 是内置复制默认插件
# 16. 逻辑复制槽在源表结构变更（ALTER TABLE）后的兼容性与故障处理 A 结构变更不影响逻辑复制 B 逻辑复制会自动同步结构变更 C 源表结构变更后需在订阅端同步 ALTER，并用 REFRESH PUBLICATION 配合，否则复制会失败 ✓ 正确答案 D 逻辑复制槽无法处理结构差异
# 17. max_connections 打满时的应急（pg_terminate_backend、清理 idle 连接）与根因治理 A 打满时只能重启数据库 B 应急用 pg_terminate_backend 清理 idle/长连接，根治靠连接池与超时治理连接数 ✓ 正确答案 C 无脑调大 max_connections 是根治方案 D idle 连接不影响连接数
# 18. 云数据库连接代理（如 RDS Proxy）如何通过代理层保持客户端连接、后端快速重连来缩短故障转移时间并吸收连接风暴？ A 代理无法池化后端连接 B 代理会中断所有客户端连接 C 代理保持客户端连接、后端快速重连缩短故障转移时间，并池化连接吸收风暴 ✓ 正确答案 D 代理在故障转移时无能为力
