# 1. MySQL 中 wait_timeout、interactive_timeout 的影响？ A wait_timeout 作用于非交互式程序连接，interactive_timeout 作用于交互式命令行连接 ✓ 正确答案 B 两者都只作用于交互式命令行连接 C 两者含义完全相同，只是别名不同 D 连接池空闲连接超过 interactive_timeout 才会被服务端关闭
# 2. PostgreSQL 中连接与 session 的关系，连接池复用与 session 状态？ A 一个连接就是一个 session，session 级状态在连接复用时会残留 ✓ 正确答案 B 一个连接可以承载多个并发 session C 连接池复用时 PostgreSQL 会自动重置所有 session 状态 D 临时表与会话无关，连接复用后自动消失
# 3. 主流连接池，HikariCP、Druid、c3p0、DBCP 的对比？ A HikariCP 以丰富监控功能著称，是默认选择 B Spring Boot 2.x 默认使用 HikariCP，需要监控与 SQL 防护时可选 Druid ✓ 正确答案 C c3p0 是当前性能最好的连接池 D DBCP 内置 SQL 防火墙与慢 SQL 拦截
# 4. 数据库连接池（Connection Pool）的必要性，减少 TCP/握手开销、限制连接数？ A 连接池主要为了减少 SQL 语句本身的执行时间 B 连接池通过复用连接降低 TCP 握手与认证开销，并限制连接数保护数据库 ✓ 正确答案 C 连接池能无限制提高数据库吞吐量，无需考虑数据库连接上限 D 连接池与连接复用无关，只是管理工具
# 5. 连接池的关键参数，initialSize、minIdle、maxActive、maxWait？ A maxActive 是连接池中最小空闲连接数 B initialSize 必须大于 maxActive C maxWait 是连接建立超时时间，与获取连接无关 D HikariCP 的 maximumPoolSize 对应 Druid 的 maxActive，minIdle 对应 minimumIdle ✓ 正确答案
# 6. 连接池的预热（Warmup）与验证（Validation）？ A 预热是在流量高峰时动态建立连接 B test-on-borrow 在归还连接时验证，test-while-idle 在取出时验证 C 验证查询必须用复杂的大语句才能保证连接有效 D test-on-borrow 每次取出都验证，可靠性最高但增加一次往返开销 ✓ 正确答案
# 7. 连接池大小与数据库 max_connections 的规划，多应用实例 × 池大小的数学与过载保护 A 连接池可以无限分配，数据库会自动扩容 B max_connections 只影响交互式连接，不影响连接池 C 单实例池大小越大越好，不必考虑数据库上限 D 所有实例连接池总和必须小于数据库 max_connections 并预留运维余量 ✓ 正确答案
# 8. PgBouncer、ProxySQL 等外部连接池的实现？ A 它们作用在应用进程内，与 HikariCP 相同 B 外部连接池一定比进程内连接池性能高 C 它们只能用于 MySQL，不能用于 PostgreSQL D 它们独立部署在应用与数据库之间，集中管理数据库连接数 ✓ 正确答案
# 9. MySQL 中 wait_timeout 与连接保活的协同？ A 保活周期应小于 wait_timeout，才能在服务端断开前激活连接 ✓ 正确答案 B 保活周期应大于 wait_timeout 才有效 C 两者完全无关，不需要协同 D 保活只能通过回调数据库变量实现
# 10. 连接保活（Keep-Alive）的实现，心跳、空闲连接检测？ A 空闲连接检测（test-while-idle）定时验证空闲连接，失效则剔除 ✓ 正确答案 B 心跳是在连接断开后自动重连 C 保活查询必须使用重型 SQL 才有效 D 保活只对 PostgreSQL 有效，MySQL 不支持
# 11. 连接泄漏的检测，Druid 的 leakDetectionThreshold？ A 它控制连接池最大连接数 B 连接借出超过该毫秒数未归还时打印堆栈，用于定位连接泄漏 ✓ 正确答案 C 它控制连接验证查询的超时时间 D 它用于设置数据库 wait_timeout
# 12. 连接泄漏（Connection Leak）的成因，未关闭连接、异常未释放？ A 异常抛出时未在 finally 中关闭连接是常见泄漏原因，应使用 try-with-resources 保证归还 ✓ 正确答案 B 连接泄漏只发生在数据库重启时 C 连接池会自动防止一切连接泄漏，无需关心 D 连接泄漏只影响性能，不会导致连接耗尽
# 13. Druid 连接池的核心特性，监控统计、SQL 防火墙、慢 SQL 拦截与连接泄漏检测如何工作？与 HikariCP 相比现在还有哪些选型价值？ A HikariCP 内置 SQL 防火墙与监控面板 B 两者都不支持连接泄漏检测 C Druid 性能一定比 HikariCP 高 D Druid 通过 Filter 体系提供监控统计、SQL 防火墙、慢 SQL 拦截与泄漏检测，与性能导向的 HikariCP 形成差异化 ✓ 正确答案
# 14. HikariCP 的优势来源，字节码精简、FastList 与并发集合优化如何降低获取连接的延迟，其参数调优（maximumPoolSize 等）的关键点？ A HikariCP 不使用并发集合，全靠单线程 B HikariCP 依赖大量复杂代码实现高性能 C maximumPoolSize 越大性能一定越高 D HikariCP 通过 FastList 和字节码精简减少连接获取/归还开销，maximumPoolSize 应按并发压测确定而非越大越好 ✓ 正确答案
# 15. 连接复用时会话状态的残留（SET 变量、临时表、用户变量）对业务的影响与清理 A SET 变量、临时表等会话状态会残留并污染后续请求，需用 DISCARD ALL/RESET CONNECTION 清理 ✓ 正确答案 B 连接复用不会残留任何会话状态 C 临时表在事务提交后自动全库清理，无需关心 D 会话状态残留只影响性能不影响数据正确性
# 16. 连接池与长事务的相互影响，长事务长时间占用池连接导致池耗尽，如何用事务超时、连接最长持有时间与慢 SQL 告警治理？ A 长事务只影响连接数量，不影响数据库锁 B 长事务不会影响连接池，可以无限运行 C 事务超时只能靠数据库 DBA 人工设置 D 长事务会长时间占用池连接，导致池耗尽，需用事务超时、慢 SQL 告警治理 ✓ 正确答案
# 17. 坏连接剔除与故障转移，数据库重启/网络闪断后连接池如何检测并剔除失效连接（validation 查询、错误分类），避免雪崩？ A 数据库重启后失效连接会自动被客户端感知，无需检测 B 通过 validation 查询与错误分类剔除失效连接，并限速重建避免连接风暴雪崩 ✓ 正确答案 C 失效连接应保留在池中，等待数据库自动恢复 D 连接池永远无法感知数据库重启
# 18. 连接池的监控指标，活跃/空闲/等待连接数、获取等待时间与拒绝次数如何采集与告警，连接池容量与数据库 max_connections 的联动治理？ A 活跃连接数接近 maxActive 且等待激增时应仅考虑加大池，无需排查数据库 B 连接池监控指标无法采集，只能人工观察 C 通过活跃/等待/获取超时等指标采集告警，池容量需与数据库 max_connections 联动预留余量 ✓ 正确答案 D 连接池容量可以无限大于数据库 max_connections
# 19. 多数据源与读写分离下的连接池设计，主库/从库连接池独立配置的依据，动态数据源切换时连接与事务的绑定如何保证？ A 主库与从库应共用同一连接池 B 主从库独立配置连接池，事务开启后连接绑定到固定数据源，不能中途切换 ✓ 正确答案 C 动态数据源切换可以在事务中途随意更换数据源 D 读写分离不需要独立连接池，只需一个连接池
# 20. 连接池连接的前置初始化（初始化 SQL）与字符集/时区设置 A 每个连接必须手动单独设置字符集 B 初始化 SQL 与字符集时区无关，只用于建表 C 初始化 SQL 用于建立连接时统一设置字符集、时区等会话环境，保证连接状态一致 ✓ 正确答案 D 初始化 SQL 会降低连接池性能，不能使用
