为什么 HikariCP 的 dataSourceClassName 常配错
多数人直接照搬 MySQL 驱动类名 com.mysql.cj.jdbc.MysqlDataSource，但 HikariCP 默认走的是 JDBC URL 自动发现机制，强行指定 dataSourceClassName 反而绕过连接池对 URL 参数的解析（比如 useSSL=false 不生效），还可能触发 ClassLoader 冲突。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 优先用
jdbcUrl+driverClassName组合，例如：jdbc:mysql://localhost:3306/test?serverTimezone=UTC&useSSL=false - 若必须用数据源类（如需复用已有
DataSource实例），确保该类实现了javax.sql.DataSource且无参构造可用 -
mysql-connector-java8.0+ 中，driverClassName已非必需，但显式写上能避免 JDK 11+ 下 ServiceLoader 查找失败
空闲连接被数据库主动断开怎么办
MySQL 默认 wait_timeout=28800（8 小时），而 HikariCP 的 connectionTimeout 控制的是获取连接的等待时间，不是连接保活——它不负责心跳检测。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 设
keepaliveTime（>=30000，单位毫秒），HikariCP 会定期检查空闲连接并尝试执行isValid() - 配
validationTimeout（建议 3000），避免验证卡住线程 - 数据库端同步调低
wait_timeout（如设为 300），让双方超时策略对齐，避免连接池里留着“假活”连接 - 别碰
testOnBorrow—— HikariCP 已废弃该参数，用connectionTestQuery也不推荐（性能差），应依赖isValid()
maximumPoolSize 设多大才不翻车
设成 100 看似很“稳”，但实际可能压垮数据库或引发线程饥饿。HikariCP 的连接不是越“多”越好，而是要匹配 DB 的最大并发连接数、应用的平均响应时间和线程模型。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 先查数据库上限：
SHOW VARIABLES LIKE 'max_connections';，预留 20% 给后台任务 - 估算公式：
(平均请求耗时 ms / 1000) × QPS × 1.5，再向上取整；例如平均 200ms、QPS 50 → (0.2 × 50) × 1.5 ≈ 15 - 生产环境慎用
allowPoolSuspension=true，它会让连接池在获取不到连接时阻塞而非抛异常，掩盖真实瓶颈 - 配合
metricRegistry（如 Dropwizard Metrics）暴露activeConnections指标，比拍脑袋设值靠谱得多
Spring Boot 2.4+ 里 HikariDataSource 自动配置突然失效
不是 HikariCP 本身坏了，而是 Spring Boot 2.4 开始默认禁用 spring.datasource.type 推导，且 spring.datasource.hikari.* 配置项若拼写错误（比如写成 hikra）也不会报错，只会静默回退到 BasicDataSource。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 检查
application.yml是否用了spring.datasource.hikari.maximum-pool-size（注意是短横线，不是驼峰） - 加一行
logging.level.com.zaxxer.hikari=DEBUG，启动时看是否输出HikariConfig加载日志 - 排除
tomcat-jdbc或dbcp2依赖，它们会干扰自动配置顺序 - 如果用了
@Configuration手动定义HikariDataSource，记得加@Primary，否则 Spring 可能注入了别的 DataSource
真正难的从来不是配几个参数，而是搞清哪个环节在静默吞掉你的配置——比如 YAML 缩进错一位、profile 没激活、或者某个 starter 里自带了冲突的 autoconfigure 类。
