Spring Boot 2.6默认使用HikariCP，需显式配置maximum-pool-size等参数并适配MySQL 8.0.22+的健康检查，否则易因连接池瓶颈或假死导致性能问题。
Spring Boot 2.6版本默认使用 HikariCP 作为数据源连接池，但其 Starter 自动配置存在隐式行为——若未显式声明连接池参数，会启用保守默认值（如 maximum-pool-size=10），在中高并发场景下极易成为性能瓶颈；同时，MySQL 8.0.22+ 的 isValid() 健康检查机制与旧版 validation-query 冲突，导致连接假死不剔除。
确认当前生效的 MySQL 连接上限
登录 MySQL 执行：SHOW VARIABLES LIKE 'max_connections';
注意：该值可能被 my.cnf 中的 [mysqld] 段覆盖，或被云厂商（如阿里云 RDS）强制限制；若返回 151，说明未调优，必须先改服务端上限再配应用层池子，否则 maximumPoolSize 设再大也无效。
执行 SET GLOBAL max_connections = 400; 临时生效（重启失效），长期生效需写入配置文件并重启 mysqld。
Spring Boot 2.6 中 HikariCP 显式配置
在 application.yml 中完整覆盖默认配置，避免依赖 Starter 的“智能推断”：
方法一：基础安全配置（适用于 QPS ≤ 300 的业务）
spring:
datasource:
url: jdbc:mysql://10.0.1.20:3306/appdb?serverTimezone=Asia/Shanghai&useSSL=false&allowPublicKeyRetrieval=true
username: appuser
password: 'xxx'
hikari:
maximum-pool-size: 16
minimum-idle: 6
connection-timeout: 2000
idle-timeout: 600000
max-lifetime: 1800000
keepalive-time: 300000
connection-test-query: SELECT 1
方法二：适配 MySQL 8.0.22+ 的轻量验证（必须用，否则连接池无法识别服务端主动断连）
将 connection-test-query 替换为：
connection-init-sql: SELECT 1
initialization-fail-timeout: 3000
validation-timeout: 3000
isolate-internal-queries: true
注意：HikariCP 5.0+ 已废弃 connection-test-query，改用 isValid() 内置检测，但 Spring Boot 2.6 默认集成的是 HikariCP 4.0.x，仍需保留 SELECT 1；升级到 Spring Boot 3.x 后才可彻底移除该配置。
压测前必做的三项校验
第一步：验证连接池是否真正接管连接
启动应用后，执行 SELECT * FROM information_schema.PROCESSLIST WHERE USER='appuser';，观察活跃连接数是否稳定在 minimum-idle～maximum-pool-size 区间内；若持续为 1 或飙升至 max_connections 上限，说明配置未生效。
第二步：触发一次连接失效模拟
手动 kill 一个 PROCESSLIST 中的 Sleep 连接（KILL 12345;），等待 idle-timeout 秒后，再次查 PROCESSLIST，确认该连接已消失且无新连接补位失败日志。
第三步：检查 HikariCP 内置指标
访问 /actuator/metrics/hikaricp.connections.active（需启用 actuator），确认 active 值峰值不超过 maximum-pool-size；若 consistently near maximum，说明 SQL 执行慢或连接未 close，需查代码里是否有 ResultSet/Statement 未关闭。
