MySQL连接数爆满主因是未释放或阻塞连接，应查Threads_connected是否接近max_connections、Threads_running是否偏低，并用SHOW FULL PROCESSLIST定位Time>60且State非Sleep的异常线程。
phpEnv 本身不管理 MySQL 连接数，它只是 Windows 下的 PHP + MySQL + Apache/Nginx 一键集成环境。连接数爆满不是 phpEnv 的锅，而是你本地运行的 MySQL 实例被大量未释放、阻塞或异常连接占满。解决重点在 MySQL 层排查，而非改 phpEnv 配置。
怎么看当前 MySQL 连接是否真爆了
别光看任务管理器或 phpEnv 控制面板上那个“MySQL 已启动”——它不反映连接状态。先确认真实水位：
-
SHOW GLOBAL STATUS LIKE 'Threads_connected';查当前总连接数 -
SHOW GLOBAL STATUS LIKE 'Threads_running';查真正干活的连接数（非 Sleep） -
SHOW VARIABLES LIKE 'max_connections';看上限，默认是 151，phpEnv一般没改过
如果 Threads_connected 接近甚至等于 max_connections，且 Threads_running 很低（比如 2–5），基本就是大量连接卡在 Sleep 或 Waiting 状态没释放。
用 SHOW FULL PROCESSLIST 快速揪出异常线程
phpEnv 自带的 phpMyAdmin 或命令行都能执行，但必须用 SHOW FULL PROCESSLIST;（注意是 FULL）——否则看不到完整 SQL，容易漏掉关键线索。
- 重点关注
State列：不是Sleep的都要看，尤其是Waiting for table metadata lock、Updating、Sending data、Locked - 看
Time列：超过 60 秒的非 Sleep 线程，99% 是问题源头；超过 300 秒的基本可直接 kill - 看
User和Host：如果是root@localhost或admin@127.0.0.1，很可能是你本地某个脚本、浏览器插件或 phpMyAdmin 页面挂着没关
别在 phpEnv 里反复刷 processlist
phpEnv 默认用的是 MySQL 5.7 或 8.0，而 information_schema.processlist 是临时表，高频率查它会触发全局扫描锁——你自己越查，数据库越卡，甚至导致新连接建立失败。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
performance_schema.processlist（需确认已开启：SELECT VARIABLE_VALUE FROM performance_schema.global_variables WHERE VARIABLE_NAME = 'performance_schema';返回ON才能用） - 如果只是临时诊断，用这条语句一次过滤到位：
SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM performance_schema.processlist WHERE COMMAND != 'Sleep' AND TIME > 60 ORDER BY TIME DESC; - 避免写循环脚本每 5 秒自动
KILL——Binlog Dump、Connect类线程可能是复制或监控必需的，误杀会导致 phpMyAdmin 刷新失败或从库断连
phpEnv 场景下最常踩的坑
你在 phpEnv 里跑测试项目、本地开发或小工具，连接暴增往往和生产环境逻辑不同，但更容易被忽略：
- 浏览器开着多个 phpMyAdmin 标签页，每个都维持一个长连接；关掉标签页后连接未必立刻断，尤其用了 HTTP Keep-Alive
- PHP 脚本里写了
mysql_connect()或new mysqli()却没配mysqli_close()，或者放在循环里反复 new 不 close - 用 PDO 时没设
PDO::ATTR_PERSISTENT => false，启用了持久连接但没控制生命周期，连接堆积在 MySQL 进程里不释放 -
phpEnv自带的 MySQL 没调优：wait_timeout默认 28800 秒（8 小时），本地开发根本不需要这么长，建议改成300（5 分钟）：SET GLOBAL wait_timeout = 300;
真正难处理的不是连接多，而是那些 State 为 Waiting for table metadata lock 的线程——它们通常由一个没提交的事务或 DDL 操作卡住，后面所有连进来的操作全被堵死，但 CPU 和 IO 看不出压力。这种时候光 kill 新连接没用，得先找到并 kill 最早那个“锁源”。
