Apache错误日志无法直接显示数据库连接泄露，但可通过“Too many connections”“PoolExhaustedException”“Connection refused”等异常信号识别；需结合mysqladmin Threads_connected、ss/netstat连接状态及代码级日志（如Hikari DEBUG日志、PHP error_log跟踪）交叉验证，并检查KeepAlive、MaxRequestWorkers、持久连接等配置干扰。
直接看 Apache 错误日志本身，无法直接发现数据库连接句柄泄露——因为句柄泄露是应用层（PHP/Java 等）未正确关闭数据库连接导致的资源耗尽问题，它不会在 Apache 日志里写“连接没关”；但日志里会出现一系列高度相关的异常信号，可作为关键突破口。
盯紧这几类错误关键词
在 /var/log/apache2/error.log（或对应路径）中逐行搜索以下内容：
-
“Too many connections”：MySQL 已达
max_connections上限，是泄露最典型的外在表现； - “Connection refused” / “Connection timed out” / “Can’t connect to MySQL server”：不是网络问题，而是连接池已空、新请求拿不到连接；
- “mysqli_connect(): (HY000/2002)” 或 “PDO::__construct(): SQLSTATE[HY000] [2002]”：说明连接建立失败，常伴随超时或拒绝；
- “PoolExhaustedException”（Tomcat 场景）或 “HikariPool-1 - Connection is not available”（Spring Boot + Hikari）：明确指向连接池枯竭；
- 反复出现的 “PHP Warning: mysqli::query(): MySQL server has gone away”：连接被 MySQL 主动断开（如 wait_timeout 触发），但 PHP 仍尝试复用，说明连接状态管理失效。
结合系统与数据库指标交叉验证
单看日志不够，必须联动查证：
- 执行
mysqladmin -u root -p extended-status | grep Threads_connected：若数值持续接近或等于max_connections，且不随流量下降而回落，基本确认连接未释放； - 运行
ss -s | grep tcp或netstat -an | grep :3306 | grep -E 'ESTABLISHED|TIME_WAIT' | wc -l：ESTABLISHED 连接数长期高位、TIME_WAIT 大量堆积，说明连接未正常关闭或复用策略失当； - 检查 Apache 子进程存活时间：若
MaxConnectionsPerChild设置过大（如 0 或极大值），配合持久连接，会导致连接在 DB 侧过期后仍被 PHP 持有，形成“僵尸连接”。
定位到具体代码位置的方法
日志只告诉你“出事了”，要找到哪段代码漏关连接：
- 在 PHP 中开启连接跟踪：在关键数据库操作前后加
error_log("DB start: " . microtime(true), 4)和error_log("DB end: " . microtime(true), 4)，观察是否有“start”无“end”； - 启用 PDO 或 mysqli 的异常模式：
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION)，让未捕获的异常暴露调用栈； - 对 Java 应用（Tomcat/Spring Boot），开启连接池 DEBUG 日志：
logging.level.com.zaxxer.hikari=DEBUG或配置 Tomcat JMX，实时查看active、idle连接数变化趋势； - 检查所有
try...catch块：重点看finally中是否遗漏$conn->close()或$stmt->close()，尤其在 return 或 throw 前。
别忽略 Apache 自身配置干扰
某些 Apache 配置会掩盖或加剧泄露症状：
-
KeepAlive On且KeepAliveTimeout过长：导致子进程长时间存活，加剧持久连接失效风险； -
MaxRequestWorkers设置过高，超过 MySQLmax_connections— 系统保留连接（如监控脚本）的余量，造成请求排队等待连接，日志中表现为大量超时而非直接报错； - 使用 prefork MPM 时开启
mysqli.default_persistent=On：每个子进程独立维护连接，极易因泄漏快速占满 DB 连接数，且无法跨进程复用，实际收益极低。
