java中连接池本身不直接记录慢sql，需协同mysql慢查询日志、druid监控或hikaricp+应用层埋点实现定位；关键路径为：开启mysql慢日志（slow_query_log=1, long_query_time=1）、druid配置slow-sql-millis与监控页、hikaricp结合jdbc日志/mybatis拦截/链路追踪及连接池指标分析。
Java 中连接池本身不直接记录慢 SQL，但主流连接池（如 HikariCP、Druid）可通过集成数据库监控能力或配合 MySQL 慢查询日志 + 应用层埋点，实现对慢 SQL 的捕获与定位。关键在于“协同诊断”，而非依赖单一组件。
启用数据库端慢查询日志
这是最基础、最可靠的源头数据来源。MySQL 必须开启并配置合理阈值：
- 在 my.cnf 的 [mysqld] 下添加：
slow_query_log = 1 slow_query_log_file = /var/log/mysql/slow.log long_query_time = 1.0 # 单位：秒，建议从 1s 开始，避免日志爆炸
- 重启 MySQL 或执行
SET GLOBAL slow_query_log = ON;临时生效 - 确认开启后，所有超时 SQL 会写入日志文件，包含执行时间、锁等待、扫描行数等关键字段
利用 Druid 的内置 SQL 监控能力
Druid 提供开箱即用的 SQL 审计与统计面板，适合快速定位问题 SQL：
- 引入依赖：
druid-spring-boot-starter - 配置开启监控和慢 SQL 记录：
spring:
datasource:
druid:
web-stat-filter:
enabled: true
stat-view-servlet:
enabled: true
url-pattern: /druid/*
filter:
stat:
log-slow-sql: true
slow-sql-millis: 1000 # 超过 1s 记为慢 SQL
- 访问
/druid控制台，可查看 SQL 列表、执行次数、平均耗时、最大耗时、失败率等 - 支持按执行时间排序、导出慢 SQL、查看执行计划（EXPLAIN）
在 HikariCP 中结合应用层增强可观测性
HikariCP 本身无 SQL 日志功能，但可通过以下方式补足：
-
开启 JDBC 驱动日志：在 MySQL 连接 URL 后加参数
&profileSQL=true&useSSL=false（仅开发/测试），打印实际执行语句和耗时 -
配合 MyBatis Plus 的执行器拦截：使用
MyBatisPlusInterceptor+ 自定义InnerInterceptor，在willDoQuery和afterQuery中记录 SQL 及耗时，筛选超时语句 - 接入分布式链路追踪（如 SkyWalking、Pinpoint）：慢 SQL 会自然体现在 DB span 的 duration 和 db.statement 标签中，可下钻到具体 SQL 和调用栈
关联分析：连接池指标 + 慢 SQL + 事务行为
单看慢 SQL 不够，需结合连接池状态判断是否是“因慢致堵”：
- 检查 HikariCP 的
pool.getWaitCount()或暴露的 JMX 指标HikariPool-1.Waiting：若持续 > 0，说明线程在等连接 → 很可能被长事务或慢 SQL 占满连接 - 观察
pool.getActiveConnections()和pool.getIdleConnections()：活跃连接长期接近maximum-pool-size，且平均连接持有时间远大于 SQL 执行时间 → 存在未提交事务或连接未关闭 - 开启 HikariCP 泄漏检测：
leak-detection-threshold=60000（毫秒），一旦触发会打印借出连接时的完整堆栈，直指业务代码中未 close() 或未正确释放事务的位置
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
