Hyperf 3.1 MySQL 报 Too many connections 的主因是 MySQL max_connections 设置过低或 Linux 文件句柄限制不足，需依次检查并调高 max_connections、提升系统级 nofile 限制、合理配置 Hyperf 连接池（如 max_connections 设为 30–80）、启用健康检测，并通过 SHOW PROCESSLIST 定位泄漏源。
Hyperf 3.1 中 MySQL 报 Too many connections，通常不是框架或应用代码直接导致的连接泄漏，而是底层资源限制与配置不匹配引发的系统级瓶颈。重点要查清：连接数是否真超 MySQL 的 max_connections？还是 Linux 文件句柄（file descriptor）先耗尽，导致 MySQL 根本无法接受新连接？
确认 MySQL 实际允许的最大连接数
登录 MySQL 执行：
SHOW VARIABLES LIKE 'max_connections';
默认值通常是 151，高配服务器也常被设为 500–1000。如果 Hyperf 应用两个实例、每个连接池 max=200，已占 400 连接，再叠加监控、备份、DBA 工具等临时连接，很容易触顶。
- 临时调高（仅验证用）：
SET GLOBAL max_connections = 1000; - 永久生效需修改 MySQL 配置文件（如
/etc/my.cnf或/etc/mysql/mysql.conf.d/mysqld.cnf），在[mysqld]下加：max_connections = 1000 - 改完重启 MySQL：
sudo systemctl restart mysql
检查并提升 Linux 文件句柄限制
Linux 中每个 TCP 连接占用一个文件描述符。MySQL 启动时会申请大量 fd，若系统限制太低（默认常为 1024），即使 max_connections 设得再高，MySQL 也起不来那么多连接。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 查看当前 MySQL 进程的 fd 限制：
cat /proc/$(pgrep mysqld)/limits | grep "Max open files" - 编辑
/etc/security/limits.conf，追加两行：* soft nofile 65535* hard nofile 65535 - 对 MySQL 服务单独加固（推荐）：
在/etc/systemd/system/mysqld.service.d/override.conf中添加：[Service]LimitNOFILE=65535 - 重载 systemd 并重启 MySQL：
sudo systemctl daemon-reload && sudo systemctl restart mysql
优化 Hyperf 连接池配置
Hyperf 默认使用 Swoole 协程 MySQL 客户端，连接由协程池管理。避免“每个请求都新建连接”，必须严格控制池大小和生命周期。
- 检查
config/autoload/databases.php中对应数据库的配置：
确保'max_connections' => 50（而非 200）——多数业务 30–80 足够，过高反而加剧争抢 - 启用连接健康检测（防僵死连接）：
'options' => [PDO::ATTR_TIMEOUT => 3],
配合'pool' => ['min_connections' => 5, 'max_idle_time' => 60] - 禁用长连接自动重连（避免雪崩）：
不建议设'reconnect' => true，应靠连接池回收+异常捕获重试逻辑来兜底
排查真实连接来源与泄漏点
执行 SHOW PROCESSLIST; 查看当前活跃连接。重点关注：
- 大量
Sleep状态且Time值很高 → 可能是连接未正确释放（比如协程退出前没 close 或没 return 到池） - 来源 IP 是应用服务器但 User 显示为
hyperf_app→ 确认是否多个部署单元（如灰度实例、定时任务容器）重复建池 - 连接数随请求 QPS 线性上涨不回落 → 检查是否有 DAO 层手动 new PDO、未走 DI 容器注入的连接
可在 Hyperf\Database\Connection 上加日志钩子，统计每次获取/释放连接的协程 ID 和堆栈，快速定位未归还点。
