在 phpEnv 下查 MySQL 当前活跃线程，最直接方式是登录后执行 SHOW FULL PROCESSLIST;（root 默认无密码，权限通常已开）；若 INFO 为空，可设 SET GLOBAL show_compatibility_56 = ON; 或改用命令行工具避免截断。
phpEnv 环境下怎么查 MySQL 当前活跃线程
phpEnv 是 Windows 下的集成环境（类似 XAMPP），其 MySQL 实例本质仍是标准 MySQL 服务，只是默认权限、端口和配置做了简化。查活跃线程的核心命令不变，但要注意：它默认用 root 用户且无密码，PROCESS 权限通常已开启；但若你改过 root 密码或禁用了该权限，SHOW PROCESSLIST 可能只返回空或仅自身连接。
- 直接登录后执行
SHOW PROCESSLIST;—— 最快验证方式，能看到 ID、User、Host、DB、Command、Time、State、Info 八列 - 如果只看到一行（自己当前连接），说明没权限看别人，需确认是否以
root登录：SELECT USER(), CURRENT_USER();，前者是客户端声明身份，后者才是 MySQL 实际认证用户 - phpEnv 自带的 phpMyAdmin 里也能查：点击「状态」→「进程」标签页，底层就是调用
SHOW FULL PROCESSLIST，但会自动截断长 SQL；如需完整语句，仍建议进命令行 - 注意 Time 列单位是秒，不是毫秒；State 为
Sleep且 Time > 300 的连接，大概率是应用层未正确 close 的空闲连接，不是“正在干活”
为什么 information_schema.PROCESSLIST 查不到 INFO 内容
在 phpEnv 的 MySQL（尤其 8.0+ 版本）中，即使你有 SELECT 权限，SELECT * FROM information_schema.PROCESSLIST 返回的 INFO 列也常为 NULL。这不是 bug，而是安全限制：MySQL 8.0 默认关闭了 show_compatibility_56，且把敏感字段（如正在执行的 SQL）设为不可见。
- 临时解决：执行
SET GLOBAL show_compatibility_56 = ON;（需 SUPER 权限；phpEnv 中 root 一般有） - 更稳妥的方式是用
SHOW FULL PROCESSLIST;—— 它绕过 information_schema，直接从内存读取，INFO 不会被清空 - 如果连
SHOW FULL PROCESSLIST的 INFO 也被截断（比如只显示前 100 字符），那是客户端设置问题；phpEnv 自带的命令行工具（如 MySQL Console）通常无此限制，而某些第三方终端可能做了截断 - 别试图用
performance_schema.threads替代 —— 它不存 SQL 文本，PROCESSLIST表才是唯一带INFO的来源
如何快速定位卡住的事务或锁等待
phpEnv 常用于本地开发调试，事务卡住往往是因为忘了 COMMIT 或代码异常退出导致连接未释放。单靠 SHOW PROCESSLIST 很难发现锁等待，因为 State 显示 Locked 或 Waiting for table metadata lock 并不明确指向 InnoDB 行锁。
- 先查活跃事务：
SELECT * FROM information_schema.INNODB_TRX\G，重点关注trx_state = 'LOCK WAIT'和trx_started时间 - 再查谁在阻塞：
SELECT * FROM performance_schema.data_lock_waits\G（MySQL 8.0+）或SELECT * FROM information_schema.INNODB_LOCK_WAITS\G（5.7 及以前） - 结合
PROCESSLIST关联线程：SELECT p.ID, p.USER, p.HOST, p.INFO, t.trx_state FROM information_schema.PROCESSLIST p JOIN information_schema.INNODB_TRX t ON p.ID = t.trx_mysql_thread_id WHERE t.trx_state = 'LOCK WAIT'; - phpEnv 默认没开
performance_schema？检查SHOW VARIABLES LIKE 'performance_schema';，若为OFF，需编辑my.ini（通常在 phpEnv 安装目录下的mysql\bin\或mysql\conf\）加一行performance_schema = ON，然后重启 MySQL 服务
phpEnv 中 KILL CONNECTION 安全吗
安全，但要分场景。phpEnv 是本地环境，没有并发用户或线上业务压力，KILL CONNECTION 终止一个线程不会影响 MySQL 服务本身，也不会损坏数据 —— 它只是断开 TCP 连接并回滚该连接上的未提交事务。
立即学习“PHP免费学习笔记（深入）”；
- 优先用
KILL QUERY <code>ID;：只终止当前 SQL，连接保持，适合你在 phpMyAdmin 或命令行误执行了大查询，想中断但不想重连 -
KILL CONNECTION <code>ID; 会强制关闭连接，对应的应用层（如 PHP 脚本）可能抛出MySQL server has gone away异常，但这是预期行为 - 别 KILL MySQL 自己的后台线程（ID ≤ 3 的那些），比如
Event Scheduler或Daemon类型 Command，它们不是客户端连接 - phpEnv 启动脚本里常带 “MySQL 服务” 图标，右键可“重启服务”，这比手动 KILL 更彻底，适合卡死无法响应时兜底
真正容易被忽略的是：phpEnv 的 MySQL 配置文件（my.ini）里 max_connections 默认值往往只有 150，本地开发跑多个 Laravel/Symfony 项目时，很容易因连接池复用不当触发“Too many connections”。与其频繁 KILL，不如查 SHOW STATUS LIKE 'Threads_connected'; 和 SHOW STATUS LIKE 'Aborted_connects';，确认是连接泄漏还是认证失败堆积。
