应用层与ProxySQL代理层是否需同时启用连接池？

核心结论 #

应该在应用层启用连接池，但需与ProxySQL的连接池配置协同，避免多层池的资源冲突和性能损耗。

为什么需要同时启用应用层连接池？ #

• 降低应用与ProxySQL间的TCP连接开销：ProxySQL的连接池负责与后端MySQL的连接复用，但应用到ProxySQL的TCP连接仍有建立/销毁成本，应用层池可复用这些连接，减少握手延迟。
• 适配业务请求模式：应用层连接池（如.NET的SqlConnection池、SpringBoot的HikariCP）可根据自身业务的并发峰值、请求频率做更细粒度的连接调度，比ProxySQL更贴近业务场景。
• 缓冲限流，保护ProxySQL：若应用层无连接池，短时间高并发请求会直接打满ProxySQL的连接池，引发连接拒绝；应用层池可起到缓冲作用，平滑请求流量。

多层连接池的配置最佳实践 #

1. 对齐连接池大小 #

应用层连接池的最大连接数建议设置为ProxySQL对应单Galera节点连接池上限的70%-80%，避免ProxySQL后端连接被占满。

• 示例：若ProxySQL配置每个Galera节点的最大连接数为100，则应用层每个实例的最大连接数设为70-80。

2. 协同配置超时参数 #

确保应用层的超时参数短于ProxySQL的对应参数，避免应用持有已被ProxySQL回收的失效连接：

• 应用层：
  • .NET连接字符串配置：Max Pool Size=70;Connection Timeout=10;Idle Timeout=240（Idle Timeout比ProxySQL的后端空闲超时短）
  • SpringBoot HikariCP配置：

    spring:
      datasource:
        hikari:
          maximum-pool-size: 70
          connection-timeout: 10000  # 10秒
          idle-timeout: 240000       # 4分钟，短于ProxySQL的mysql-server_idle_timeout
          max-lifetime: 300000       # 5分钟，短于ProxySQL的连接生命周期
    

• ProxySQL：配置mysql-server_connect_timeout=5000（5秒）、mysql-server_idle_timeout=300000（5分钟），确保后端连接失效时及时回收。

3. 针对不同框架的细节配置 #

• .NET：无需额外开启连接池（默认启用），避免手动调用SqlConnection.ClearAllPools()（除非故障恢复场景），依赖默认的池自动管理。
• SpringBoot：优先使用默认的HikariCP（性能优于其他池实现），避免同时启用多个连接池组件，确保配置只作用于HikariCP。

4. 监控与动态调优 #

• 监控ProxySQL连接状态：执行SELECT * FROM stats_mysql_connection_pool;查看used_connections、free_connections，确保未接近上限。
• 监控应用层连接池：
  • .NET：通过Windows性能计数器（.NET Data Provider for SqlServer分类）查看活跃/空闲连接数、排队请求数。
  • SpringBoot：启用Actuator，通过/actuator/hikaricp端点查看池的使用状态、连接超时次数。
• 根据业务波动调整：促销等峰值期临时调高应用层和ProxySQL的连接数，低谷期调低，减少资源闲置。

常见误区规避 #

• 不要禁用应用层连接池：仅依赖ProxySQL池会导致大量短连接，增加TCP握手开销，拖慢ProxySQL性能。
• 不要设置过大的应用层连接数：会导致ProxySQL后端连接被占满，引发MySQL的Too many connections错误。
• 不要忽略超时参数对齐：应用层闲置超时若长于ProxySQL，会出现应用拿到已失效连接的情况，引发Connection reset by peer类错误。

内容的提问来源于stack exchange，提问作者MiH