<p>phpEnv 中 SHOW PROCESSLIST 无反应或仅显示自身连接，主因是 root 用户缺少 PROCESS 权限；需执行 GRANT PROCESS ON . TO 'root'@'localhost'; 并用 SHOW FULL PROCESSLIST 查看完整 SQL，或通过 performance_schema.threads 替代。</p>
phpEnv 里执行 SHOW PROCESSLIST 没反应或只看到自己连接
phpEnv 是 Windows 下的集成环境，MySQL 默认以服务方式运行，但它的权限模型和标准 MySQL 完全一致。直接在 phpMyAdmin 或命令行执行 SHOW PROCESSLIST 返回空、只有 1–2 行，大概率不是没连接，而是当前登录用户（通常是 root）没被显式授予 PROCESS 权限。
phpEnv 自带的 MySQL 配置通常不会自动给 root@localhost 授予 PROCESS，哪怕密码正确、能建库删表，也看不到别人连接。验证方法：执行 SELECT CURRENT_USER(); 看实际登录身份，再查权限：SHOW GRANTS FOR CURRENT_USER; —— 如果输出里没有 PROCESS ON *.*，就确认是权限问题。
- 临时解决：用 phpEnv 自带的 MySQL 命令行工具（如
mysql.exe），以管理员身份运行，登录后执行：GRANT PROCESS ON *.* TO 'root'@'localhost'; FLUSH PRIVILEGES; - 注意：phpEnv 的 MySQL 配置文件（
my.ini）一般位于phpEnv\MySQL\my.ini，但改配置不能绕过权限检查，必须授予权限 - 云/虚拟环境（如 WSL 共享目录）下，
localhost和127.0.0.1可能匹配不同权限规则，优先试'root'@'127.0.0.1'
想看完整 SQL 却发现 Info 字段被截断
默认 SHOW PROCESSLIST 的 Info 列最多显示 100 字符，长查询、带参数的预处理语句、ORM 自动生成的 SQL 都会被砍掉，看不出真实执行内容。这不是 phpEnv 特有，是 MySQL 服务端行为。
必须用 SHOW FULL PROCESSLIST —— 注意是 FULL，不是 ALL（ALL 是另一个权限关键字，和显示长度无关）。在 phpMyAdmin 的 SQL 标签页里粘贴执行即可；如果用命令行，确保输入完整命令，别漏掉 FULL。
立即学习“PHP免费学习笔记（深入）”；
-
SHOW PROCESSLIST→ Info 最多 100 字符 -
SHOW FULL PROCESSLIST→ Info 不截断（但超长仍可能被客户端 UI 折行，建议复制到编辑器看） - phpMyAdmin 有些旧版本会默认隐藏
FULL输出，可手动在 SQL 输入框中强制执行
没 PROCESS 权限时，用 performance_schema.threads 替代
MySQL 5.6+（phpEnv 多数用 5.7 或 8.0）默认开启 performance_schema，只要账号有 SELECT 权限就能查 performance_schema.threads，它不走权限过滤逻辑，能看到所有线程基础信息，比 information_schema.PROCESSLIST 更可靠（后者在 8.0.22+ 已废弃且字段固定）。
执行这条 SQL：
SELECT thread_id, processlist_user, processlist_host, processlist_db, processlist_command, processlist_state, processlist_info FROM performance_schema.threads WHERE PROCESSLIST_ID IS NOT NULL;
注意：processlist_info 在部分 phpEnv 打包版本中可能为 NULL，因为默认禁用了语句采集。需确认是否启用：SELECT * FROM performance_schema.setup_consumers WHERE NAME = 'events_statements_current';，若 ENABLED 是 NO，则需管理员执行：UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME = 'events_statements_current';
排查卡住的连接，别只盯着 Time 和 State
phpEnv 常用于本地开发，但一旦跑着 Laravel/Symfony 这类框架，容易出现“Sleep”连接堆积、事务未提交、元数据锁等待等问题。SHOW PROCESSLIST 里 Time 值大 ≠ 有问题，State 才是关键线索：
-
Waiting for table metadata lock：说明有 DDL（如ALTER TABLE）或长事务没提交，阻塞了其他操作 -
Sending data：不是网络发送，是 MySQL 正在构造结果集，配合Info看是不是GROUP BY或ORDER BY没走索引 -
Locked：MyISAM 表级锁，或 InnoDB 的行锁升级成表锁（如全表 UPDATE） - 大量
Sleep且Time > 300：可能是 PDO 没设PDO::ATTR_PERSISTENT => false，导致连接池复用异常
真正难定位的是那些 State 为空、Info 为 NULL 却长期占用连接的线程——它们往往来自框架底层连接管理逻辑，此时得结合应用日志和 SHOW ENGINE INNODB STATUS\G 查事务列表。
