# 1. 事务历史的分析，pg_stat_statements、performance_schema？ A performance_schema 只记录磁盘。 B 两者功能相同。 C pg_stat_statements 统计语句执行，performance_schema 记录事务与事件。 ✓ 正确答案 D pg_stat_statements 只记录连接。
# 2. 事务等待图的监控，pg_locks、lock_wait_timeout？ A 锁等待图无法监控。 B pg_locks/data_lock_waits 可构建锁等待图，lock_timeout 控制锁等待超时。 ✓ 正确答案 C lock_timeout 控制语句执行。 D pg_locks 不显示锁。
# 3. 事务回滚率（Rollback Rate）的监控？ A 高回滚率通常提示事务冲突频繁或逻辑错误，应监控告警。 ✓ 正确答案 B 回滚率与事务健康无关。 C 高回滚率是正常现象。 D 回滚率无法计算。
# 4. performance_schema 的事务表？ A 事务表不记录耗时。 B performance_schema 无事务表。 C 事务表只记录连接。 D events_transactions_current/history 记录事务状态、耗时与关联语句。 ✓ 正确答案
# 5. InnoDB 在不同隔离级别下的加锁策略有何差异（READ COMMITTED 基本禁用 Gap Lock、REPEATABLE READ 用 Next-Key Lock 防幻读）？同一条 SQL 为何加锁范围不同？ A RC 基本禁用 Gap Lock，RR 用 Next-Key Lock 防幻读，锁范围更大。 ✓ 正确答案 B 两级别加锁完全相同。 C RC 用 Next-Key Lock。 D RR 禁用间隙锁。
# 6. InnoDB 在 RR 下对普通索引范围查询的加锁规则（向后加锁直到第一个不满足条件的记录及其间隙）是怎样的？与唯一索引等值命中/未命中时的加锁有何差异？ A 所有查询都锁整张表。 B 普通索引范围查询锁范围及右边界间隙，唯一索引等值命中只锁记录、未命中锁间隙。 ✓ 正确答案 C 唯一索引等值命中锁间隙。 D 普通索引范围查询不锁间隙。
# 7. 如何解读 SHOW ENGINE INNODB STATUS 的 LATEST DETECTED DEADLOCK 段（两个事务各自持有与等待的锁、回滚方）？据此如何给出索引设计或事务顺序的改造方案？ A 死锁段无法解读。 B LATEST DETECTED DEADLOCK 显示两事务的持锁、等待与回滚方，据此可设计索引与加锁顺序。 ✓ 正确答案 C 死锁与加锁顺序无关。 D 死锁段不显示回滚方。
# 8. InnoDB 为什么引入意向锁（IS/IX）？加表锁时“先查意向锁再决定”的两级判定如何避免逐行扫描，从而让表锁与行锁高效共存？ A 意向锁标记表级加锁意图，加表锁时查意向锁避免逐行扫描。 ✓ 正确答案 B 意向锁需要逐行扫描。 C 意向锁与表锁无关。 D InnoDB 无意向锁。
# 9. SELECT ... FOR UPDATE NOWAIT 与 SKIP LOCKED 分别如何避免排队等待？各自的典型应用（立即失败快速返回 vs 任务队列领取）是什么？ A NOWAIT 遇到锁立即失败，SKIP LOCKED 跳过锁行，适合任务队列领取。 ✓ 正确答案 B 两者都等待锁。 C NOWAIT 适合任务队列。 D SKIP LOCKED 遇到锁立即失败。
# 10. 长事务的发现与监控（pg_locks / information_schema.innodb_trx）的工程实践 A 长事务无法定期监控。 B 用 pg_stat_activity/innodb_trx 的开始时长与锁信息识别长事务，定期监控告警。 ✓ 正确答案 C 只需看 CPU 就能发现长事务。 D 长事务不需要监控。
# 11. READ COMMITTED 下的半一致性读（semi-consistent read，对不满足 WHERE 的已锁行提前释放锁）如何减少锁冲突？它与语句级复制安全有何关系？ A 半一致性读对已锁行一律阻塞。 B 半一致性读对不满足 WHERE 的已锁行提前释放锁，减少锁冲突。 ✓ 正确答案 C 半一致性读与 RC 无关。 D 半一致性读增加锁冲突。
# 12. 死锁牺牲者选择在 MySQL（按 undo 量等代价回滚较小事务）与 PostgreSQL（终止当前检测到死锁的后端、报 40P01）上有何差异？应用应如何重试？ A PostgreSQL 报 1213。 B 两者牺牲者选择相同。 C 死锁无需重试。 D MySQL 回滚 undo 较小的牺牲者，PostgreSQL 报 40P01，应用需捕获并重试。 ✓ 正确答案
# 13. 统一锁获取顺序、缩短事务持锁时间为何能降低死锁概率？这与死锁四个必要条件（互斥、持有并等待、不可剥夺、循环等待）如何对应？ A 缩短持锁无法降低死锁概率。 B 统一顺序只影响互斥。 C 统一加锁顺序打破循环等待，缩短持锁时间减少死锁窗口。 ✓ 正确答案 D 死锁四条件无关。
# 14. PostgreSQL 通过 xmax 实现的元组锁（无间隙锁、无锁升级）与 InnoDB 基于索引加锁的本质差异是什么？ A PostgreSQL 有间隙锁。 B 两者都基于索引加锁。 C PostgreSQL 用 xmax 锁元组无间隙锁，InnoDB 基于索引加记录/间隙锁。 ✓ 正确答案 D InnoDB 用 xmax 锁元组。
# 15. pg_stat_activity 的关键字段？ A pg_stat_activity 的 state、xact_start、query、wait_event 用于会话与事务监控。 ✓ 正确答案 B pg_stat_activity 只显示连接数。 C 该视图不显示事务开始时间。 D 该视图无法显示等待事件。
# 16. 锁等待超时与死锁检测的配合，innodb_lock_wait_timeout 的作用边界、死锁检测开关（innodb_deadlock_detect）在大并发下的开销，何时关闭？ A 关闭死锁检测后锁等待无兜底。 B 死锁检测无开销。 C innodb_lock_wait_timeout 兜底锁等待，innodb_deadlock_detect 主动检测但大并发下开销大。 ✓ 正确答案 D lock_wait_timeout 只影响死锁。
# 17. 事务监控的告警设计，长事务、锁等待、回滚率与死锁次数的阈值与告警分级，如何从趋势中预判锁竞争恶化？ A 趋势分析无用。 B 只设单一阈值即可。 C 长事务、锁等待、回滚率、死锁次数设阈值分级告警，从趋势预判锁竞争恶化。 ✓ 正确答案 D 死锁次数无法监控。
# 18. 慢事务的定位与优化，如何从事务粒度（开始时间、持锁时间、语句耗时）拆解慢事务，与慢查询日志的配合？ A 从开始时间、持锁时间、语句耗时拆解慢事务，配合慢查询日志定位瓶颈。 ✓ 正确答案 B 慢事务只需看总耗时。 C 慢查询日志与事务无关。 D 持锁时间无法分析。
# 19. 死锁的应用层应对，重试机制（retry with backoff）、事务瘦身与统一加锁顺序如何落地，重试的幂等性如何保证？ A 重试无需退避。 B 死锁用 retry with backoff 重试、事务瘦身、统一加锁顺序，并用唯一键保证幂等。 ✓ 正确答案 C 事务瘦身增加死锁概率。 D 重试不保证幂等。
# 20. 主动死锁检测 vs 锁等待超时的策略对比 A 两者不能同时启用。 B 主动检测无开销。 C 超时响应比主动检测快。 D 主动死锁检测响应快但开销大，锁等待超时简单但响应慢，可配合使用。 ✓ 正确答案
