# 1. 数据库的"成本可观测性"（Cost Observability） A 成本可观测性量化并归因资源、查询、存储等成本，支撑成本优化 ✓ 正确答案 B 成本可观测性只关注 CPU 使用率 C 成本可观测性与性能观测无关 D 成本无法按业务维度归因
# 2. 慢查询分析全链路，从 slow query log 采集 → SQL 指纹归一化（pt-query-digest/pg_stat_statements）→ 执行计划对比 → 根因定位（索引缺失/统计过期/锁等待）的标准化排查流程？ A 慢查询只需看单条日志即可归因 B SQL 指纹归一化会丢失模板信息 C 流程为采集→SQL 指纹归一化→执行计划对比→根因定位 ✓ 正确答案 D 执行计划对比无法发现统计过期
# 3. 连接池监控的关键指标，活跃连接数、等待队列长度、连接获取延迟（p99）、连接泄漏检测（borrow 未归还超时告警）？HikariCP 的 leakDetectionThreshold 与 PgBouncer 的 stats 如何配合？ A HikariCP 的 leakDetectionThreshold 检测连接泄漏，PgBouncer stats 反映代理连接情况，二者配合形成两层监控 ✓ 正确答案 B 连接池只需关注连接总数 C 连接获取延迟无法监控 D 等待队列长度与连接池无关
# 4. 数据库 RED/USE 监控方法论，Rate（QPS）、Errors（失败率）、Duration（延迟分布）+ Utilization（CPU/IO/内存）、Saturation（队列深度）、Errors 如何构建完整告警体系？ A RED 面向资源，USE 面向请求 B RED 关注 Rate/Errors/Duration，USE 关注 Utilization/Saturation/Errors，二者互补构建完整告警 ✓ 正确答案 C RED 只关注 CPU D 告警体系无需分级
# 5. PostgreSQL 可观测性工具链，pg_stat_statements（SQL 统计）+ pg_stat_activity（实时会话）+ pg_stat_replication（复制延迟）+ pg_stat_bgwriter（checkpoint）+ auto_explain（自动记录慢查询计划）？ A pg_stat_statements 显示实时会话 B auto_explain 用于查看锁 C pg_stat_bgwriter 反映复制延迟 D pg_stat_statements 聚合 SQL 统计，pg_stat_activity 看实时会话，pg_stat_replication 看复制延迟，auto_explain 记录慢计划 ✓ 正确答案
# 6. MySQL Performance Schema 与 sys schema，如何通过 events_statements_summary_by_digest 定位 TOP SQL、通过 events_waits_summary_global_by_event_name 定位瓶颈资源？ A events_statements_summary_by_digest 定位瓶颈资源 B events_statements_summary_by_digest 按 SQL 指纹聚合定位 TOP SQL，events_waits_summary_global_by_event_name 定位瓶颈资源 ✓ 正确答案 C sys schema 与 Performance Schema 无关 D Performance Schema 无法统计等待事件
# 7. 数据库监控指标的采集频率与开销（perf schema 采样、慢日志开关）对生产的影响 A Performance Schema 全量开启无额外开销 B 监控采集需权衡精度与开销，如 perf schema 采样、控制慢日志范围，避免拖垮生产 ✓ 正确答案 C 慢日志记录越多越好 D 采集频率不影响性能
# 8. 数据库的"业务可观测性"（Business Observability） A 业务可观测性把数据库指标映射为业务结果（成功率、响应时间、业务吞吐） ✓ 正确答案 B 业务可观测性只关注 CPU 利用率 C 业务可观测性与用户无关 D 业务可观测性只用于技术排障
# 9. 查询性能基线与异常检测，如何建立 SQL 延迟基线（p50/p95/p99），通过同比/环比检测性能退化？计划变更（plan regression）的自动捕获与告警？ A 基线只需设一次不再更新 B 计划回归无法检测 C 同比/环比无法检测性能退化 D 用 p50/p95/p99 建基线，以同比/环比检测退化，并通过计划对比捕获 plan regression ✓ 正确答案
# 10. 分布式数据库的全链路追踪，如何将应用 trace_id 透传到数据库层（SQL comment hint），实现跨服务 + 跨分片的查询耗时归因？TiDB 的 SQL Digest 与 OceanBase 的 SQL Audit 如何对接 OpenTelemetry？ A 通过 SQL comment hint 透传 trace_id，配合 SQL Digest/Audit 导出到 OpenTelemetry 实现跨分片归因 ✓ 正确答案 B trace_id 无法透传到数据库层 C SQL Digest 与 OpenTelemetry 无关 D 跨分片查询无法归因耗时
# 11. 数据库资源饱和度预警，Buffer Pool 命中率（<99% 告警）、WAL 写入延迟、临时文件使用量、锁等待时间超阈值时的分级响应策略？ A Buffer Pool 命中率、WAL 延迟、临时文件、锁等待反映资源饱和，需按分级响应策略处理 ✓ 正确答案 B Buffer Pool 命中率低于 99% 无需关注 C 临时文件使用量与内存无关 D 锁等待无需告警
# 12. 云数据库 Performance Insights（AWS）/ DAS（阿里云）的原理，如何将等待事件（wait event）按时间切片可视化，快速区分 CPU bound vs IO bound vs Lock bound？ A 它们只展示 CPU 使用率 B 等待事件无法反映瓶颈 C 它们把 DB Load 按等待事件时间切片堆叠可视化，可区分 IO/CPU/Lock bound ✓ 正确答案 D 它们不关联 SQL
# 13. 数据库监控大盘，核心指标、告警阈值与容量预警？ A 大盘覆盖资源/数据库/存储/业务指标，阈值分级告警，并通过趋势做容量预警 ✓ 正确答案 B 大盘只需显示 CPU C 告警阈值无需分级 D 容量预警只看当前用量
# 14. MySQL 与 PostgreSQL 的等待事件体系（等待类型分类）与典型瓶颈识别 A MySQL 与 PostgreSQL 都有等待事件分类，通过等待类型占比识别 IO/锁/CPU 瓶颈 ✓ 正确答案 B 只有 MySQL 有等待事件 C 等待事件与瓶颈无关 D PostgreSQL 没有等待事件概念
# 15. 数据库 SLO/SLI 定义与错误预算，如何为数据库设定可用性（99.99%）、延迟（p99 < 10ms）、吞吐（> 50K QPS）目标，并通过 error budget 驱动容量规划？ A 错误预算是未达到 SLO 的允许额度，其消耗速率驱动变更决策与容量规划 ✓ 正确答案 B 错误预算越多越好，无需管理 C SLO 无法量化 D 容量规划与 SLO 无关
# 16. 慢查询分析与优化闭环，抓取→执行计划→索引→容量？ A 闭环为抓取→执行计划→索引/改写→容量→验证，先优化再扩容 ✓ 正确答案 B 直接扩容即可解决所有慢查询 C 执行计划分析无法发现索引问题 D 优化后无需验证
# 18. 数据库巡检清单（连接数、慢查询、锁等待、复制延迟、备份成功率）的周期检查 A 巡检只需检查空间 B 巡检清单包括连接数、慢查询、锁等待、复制延迟、备份成功率等，周期检查预防隐患 ✓ 正确答案 C 巡检是一次性行为 D 备份成功率无需检查
