执行计划、SQL 优化与性能诊断
121 EXPLAIN 与 EXPLAIN ANALYZE 的区别是？
难度： 基础
- A. EXPLAIN 只给估算，EXPLAIN ANALYZE 实际执行并给出真实时间与行数
- B. 两者结果完全一致
- C. EXPLAIN ANALYZE 不执行查询
- D. EXPLAIN 会实际执行查询
查看答案与解析
正确答案A
正确原因： EXPLAIN 展示计划估算，EXPLAIN ANALYZE 执行语句并输出实际耗时与行数。
关键边界： 对写语句用 ANALYZE 会真正写入，生产环境要谨慎。
错误选项辨析： 二者信息不同，ANALYZE 会执行，EXPLAIN 只做规划。
122 执行计划中出现 Seq Scan，说明？
难度： 基础
- A. 顺序扫描整表，小表或低选择性时可能是合理选择
- B. 查询一定很慢
- C. 索引一定失效
- D. 优化器一定出错
查看答案与解析
正确答案A
正确原因： 表小或过滤条件选择性低时，顺序扫描成本反而更低。
关键边界： 需结合 rows 估算判断是否合理，而非只看节点名。
错误选项辨析： Seq Scan 不等于慢，不意味着索引失效，也不代表规划错误。
123 Index Scan 与 Index Only Scan 的区别是？
难度： 基础
- A. 两者完全相同
- B. Index Scan 需回表取非索引列，Index Only Scan 直接由索引返回
- C. Index Only Scan 必须回表
- D. Index Scan 不经过索引
查看答案与解析
正确答案B
正确原因： 查询列都在索引中时可仅索引扫描，否则要回表。
关键边界： 可见性映射影响 Index Only Scan 的回表概率。
错误选项辨析： 仅索引扫描免回表，Index Scan 以索引定位后取行。
124 Nested Loop、Hash Join、Merge Join 的适用场景是？
难度： 进阶
- A. 三者完全相同，可任意替换
- B. 小表驱动循环、大表等值连接、已排序输入的连接
- C. Hash Join 需要索引
- D. Merge Join 只支持小表
查看答案与解析
正确答案B
正确原因： Nested Loop 适合小规模，Hash Join 适合无索引等值大连接，Merge Join 利用有序输入。
关键边界： 实际由优化器按成本选择。
错误选项辨析： 三者机制不同，Hash Join 不依赖索引，Merge Join 依赖有序输入。
125 计划中的 Sort 节点出现，说明？
难度： 基础
- A. 排序完全免费
- B. 查询结果必然错误
- C. 需要额外排序，可能是 ORDER BY 未匹配索引或去重等操作
- D. 数据库会跳过排序
查看答案与解析
正确答案C
正确原因： 排序需要额外 CPU 与内存，work_mem 不足时还会落盘。
关键边界： 让 ORDER BY 匹配索引顺序可消除 Sort 节点。
错误选项辨析： 排序有成本，不影响正确性，不会自动跳过。
126 深分页（大 OFFSET）的优化方案是？
难度： 实战
- A. 把 OFFSET 加大
- B. 去掉 ORDER BY
- C. 用上一页最后 id 的键集分页，减少被扫描丢弃的行
- D. 每次返回全部行
查看答案与解析
正确答案C
正确原因： 键集分页沿索引直接定位，扫描行数不随页数增长。
关键边界： 排序键需唯一稳定，业务要支持游标翻页。
错误选项辨析： 加大 OFFSET 更慢，去排序不稳定，全量返回不可扩展。
127 定位高频慢 SQL，通常依赖？
难度： 进阶
- A. 逐条看应用日志猜
- B. 重启数据库
- C. 删除索引
- D. pg_stat_statements 或慢查询日志按耗时聚合统计
查看答案与解析
正确答案D
正确原因： pg_stat_statements 聚合语句的调用次数与总耗时，慢日志按阈值记录。
关键边界： 需要开启相关扩展与日志配置。
错误选项辨析： 靠猜测、重启、删索引都无法定位慢 SQL。
128 work_mem 的作用是？
难度： 基础
- A. 设置数据库总内存上限
- B. 限制连接数
- C. 控制缓存大小
- D. 限制排序、哈希等操作可用的内存，超出后落盘
查看答案与解析
正确答案D
正确原因： work_mem 是每个操作可用的内存预算，用于排序与哈希。
关键边界： 每个并发操作都可能申请，不能无脑调大。
错误选项辨析： 总内存与连接数由其他参数管理，缓存是 shared_buffers。
129 shared_buffers 设置过大的风险是？
难度： 进阶
- A. 挤占系统内存引发交换，且不能替代操作系统页缓存
- B. 一定让查询变慢
- C. 自动禁用索引
- D. 数据库无法启动
查看答案与解析
正确答案A
正确原因： 超出物理内存会交换，且 PG 缓存与 OS 缓存分层，需要平衡。
关键边界： 结合命中率监控逐步调整。
错误选项辨析： 并非一定变慢或禁用索引，一般不会导致无法启动。
130 并行查询生效的前提是？
难度： 进阶
- A. 表足够大且并行度、成本阈值等参数允许
- B. 任何查询都会并行
- C. 并行不需要额外资源
- D. 并行只对写入生效
查看答案与解析
正确答案A
正确原因： 规划器评估并行收益，小查询不值得并行。
关键边界： max_parallel_workers_per_gather 与成本阈值控制并行程度。
错误选项辨析： 不是所有查询都并行，并行消耗 CPU，主要用于读取。
131 PgBouncer 连接池解决的主要问题是？
难度： 进阶
- A. 加速单条 SQL 执行
- B. 降低高频短连接对 PostgreSQL 进程创建与销毁的开销
- C. 替代数据库索引
- D. 压缩数据存储
查看答案与解析
正确答案B
正确原因： 池化复用连接，避免每次请求都 fork 新进程。
关键边界： 事务级池与会话级池语义不同，需按业务选择。
错误选项辨析： 连接池不影响单查询速度，不替代索引与存储。
132 statement_timeout 的作用是？
难度： 基础
- A. 限制连接总数
- B. 单条语句执行超时后自动取消，防止失控查询
- C. 设置语句长度
- D. 控制缓存大小
查看答案与解析
正确答案B
正确原因： statement_timeout 到点取消语句，保护数据库资源。
关键边界： lock_timeout 单独控制锁等待，二者不同。
错误选项辨析： 它不管连接数、语句长度与缓存。
133 PREPARE 语句的通用计划（generic plan）可能带来的问题是？
难度： 进阶
- A. 通用计划一定更快
- B. PREPARE 会禁用索引
- C. 计划基于通用参数生成，对特定参数可能不是最优
- D. 通用计划不占用内存
查看答案与解析
正确答案C
正确原因： 通用计划牺牲参数特化，极端参数分布下可能劣于定制计划。
关键边界： 规划器在多次执行后决定是否通用化。
错误选项辨析： 通用计划未必更快，不禁用索引，也需要缓存。
134 数据库缓存命中率低，排查方向是？
难度： 实战
- A. 直接重启数据库
- B. 把全表加载进内存
- C. 检查 shared_buffers、查询模式与索引使用，避免反复随机读盘
- D. 删除统计信息
查看答案与解析
正确答案C
正确原因： 命中率低往往与热点数据、索引缺失或缓存配置相关。
关键边界： 结合 pg_statio_user_tables 等视图定位冷热表。
错误选项辨析： 重启无效，全表进内存不现实，删统计会恶化计划。
135 诊断锁等待，应查看哪个视图组合？
难度： 基础
- A. pg_stat_statements
- B. pg_roles
- C. pg_settings
- D. pg_stat_activity 与 pg_locks 联合定位阻塞链
查看答案与解析
正确答案D
正确原因： pg_stat_activity 给出等待状态与 SQL，pg_locks 给出锁对象与持有关系。
关键边界： 阻塞链可追溯到源头会话。
错误选项辨析： 语句统计、角色、配置参数都不展示锁关系。
136 pg_stat_activity 中的 wait_event 表示？
难度： 进阶
- A. 会话的启动时间
- B. 会话执行的语句数
- C. 会话使用的端口
- D. 会话当前等待的具体事件类型，如锁、I/O 或 CPU
查看答案与解析
正确答案D
正确原因： wait_event 区分等待原因（锁、WAL、I/O 等），便于定位瓶颈。
关键边界： 结合 state 与 query 字段一起分析。
错误选项辨析： 它不是时间、语句数或端口信息。
137 一条查询从 10 秒优化到毫秒级，正确的排查路径是？
难度： 实战
- A. 先 EXPLAIN ANALYZE 看瓶颈节点，再针对索引、统计与写法优化
- B. 随机调整所有参数
- C. 直接改大内存参数
- D. 删除表重建
查看答案与解析
正确答案A
正确原因： 执行计划定位实际耗时节点，优化有的放矢。
关键边界： 改参数要有依据，避免盲调。
错误选项辨析： 随机调参、盲改内存、删表都不是诊断方法。
138 应用连接数打满数据库时，首先应？
难度： 实战
- A. 重启数据库清空连接
- B. 查看 pg_stat_activity 区分空闲、活跃与阻塞会话，再决定清理与扩容
- C. 无限提高 max_connections
- D. 禁用连接池
查看答案与解析
正确答案B
正确原因： 先区分连接状态与来源，处理泄漏与阻塞比盲目扩容有效。
关键边界： max_connections 受内存限制，不能无限提高。
错误选项辨析： 重启丢现场，无限提高会内存耗尽，禁用池反而加剧。
139 优化器选错计划，常见原因是？
难度： 进阶
- A. 数据库代码有 Bug
- B. 索引数量太少
- C. 统计信息缺失或过期，或成本参数与硬件不匹配
- D. 查询结果必然错误
查看答案与解析
正确答案C
正确原因： 计划依赖统计与成本，数据变化后需 ANALYZE。
关键边界： 可调整成本参数或用 hints 纠正个别查询。
错误选项辨析： 选错计划不等于 Bug，也不意味着结果错误。
140 表膨胀导致执行计划退化的原因是？
难度： 进阶
- A. 膨胀表自动禁用索引
- B. 膨胀让统计信息更准确
- C. 膨胀只影响写入
- D. 估算行数与扫描成本上升，索引选择与连接策略随之变化
查看答案与解析
正确答案D
正确原因： 膨胀增大表页数与成本估算，可能让优化器放弃索引。
关键边界： VACUUM 与 ANALYZE 后计划通常恢复。
错误选项辨析： 膨胀不自动禁用索引，会扭曲统计而非改善，也影响读路径。