怎样在MySQL中查看当前所有活跃用户的实时连接状态？-mysql教程-PHP中文网

最直接方式是执行show processlist，可即时查看当前用户权限范围内的活跃连接；需process权限才能查看全部，加full关键字防止sql截断，time为0表示刚建立或刚执行完，state为sleep且time过大可能表明连接泄漏。

怎样在mysql中查看当前所有活跃用户的实时连接状态？

如何用 `SHOW PROCESSLIST` 快速查看活跃连接

SHOW PROCESSLIST 是最轻量、最直接的方式，它只显示当前用户有权限看到的连接（默认不显示其他用户的，除非你有 PROCESS 权限）。执行后会列出每个连接的 ID、User、Host、db、Command、Time、State 和 Info 字段。

常见错误是直接运行却看不到全部连接——这是因为普通用户默认只能看到自己的连接。要看到所有，需先确认权限：

SELECT PRIVILEGE_TYPE FROM INFORMATION_SCHEMA.ROLE_TABLE_GRANTS WHERE GRANTEE = "'your_user'@'host'" AND TABLE_NAME = "PROCESSLIST";

或更简单地试跑 SHOW FULL PROCESSLIST，如果报错 Access denied，说明缺 PROCESS 权限。

加 FULL 关键字（即 SHOW FULL PROCESSLIST）可防止 SQL 语句被截断，尤其当 Info 列里有长查询时
Time 值为 0 表示刚建立或刚执行完；持续增长说明该连接空闲等待中（比如应用没 close）
State 显示 Sleep 但 Time 很大，大概率是连接泄漏；显示 Updating 或 Sending data 时间过长，需结合 Info 查具体 SQL

为什么推荐查 `performance_schema.threads` 而不是只依赖 `information_schema.PROCESSLIST`

information_schema.PROCESSLIST 是 SHOW PROCESSLIST 的视图封装，本质是快照式采样，且不包含线程内部状态（如是否持有锁、IO 等待等）。而 performance_schema.threads 是实时内核级线程表，字段更细、延迟更低，尤其适合排查卡顿类问题。

关键区别在于：threads 表里的 PROCESSLIST_ID 对应传统连接 ID，但多了 THREAD_OS_ID（OS 级线程 PID）、RESOURCE_GROUP_NAME、THREAD_PRIORITY 等，还能关联到 events_waits_current 查当前等待事件。

必须确保 performance_schema 已启用（启动参数 performance_schema=ON，默认开启；运行中可用 SELECT @@performance_schema; 确认）
threads 表默认只记录活跃线程（TYPE='FOREGROUND'），后台线程（如 BACKGROUND）需显式过滤
不要直接 SELECT * FROM performance_schema.threads —— 默认字段太多，建议明确投影：SELECT THREAD_ID, PROCESSLIST_ID, TYPE, NAME, PROCESSLIST_USER, PROCESSLIST_HOST, PROCESSLIST_DB, PROCESSLIST_COMMAND, PROCESSLIST_STATE FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND PROCESSLIST_ID IS NOT NULL;

如何识别并终止异常连接（`KILL` 的安全用法）

发现某个连接长时间处于 Locked 或 Waiting for table metadata lock 状态？别急着 KILL，先确认它是否真在阻塞别人：查 sys.schema_table_lock_waits（需 sys schema 启用）或用 performance_schema.data_locks + data_lock_waits 关联分析。

MySQL

编写正确的MySQL查询，避免字符集、索引和锁方面的常见陷阱。

下载

KILL 分两种：KILL CONNECTION <code>ID（断开连接，释放所有资源）和 KILL QUERY <code>ID（只中断当前语句，连接保持）。后者更安全，尤其对长事务或批量导入场景。

KILL 操作本身会进入队列，并非立即生效；若目标连接正执行不可中断操作（如写 binlog、刷脏页），可能需数秒才响应
禁止对 system user 或 unauthenticated user 执行 KILL，可能引发 mysqld 意外退出
生产环境建议加条件判断再 kill，例如：KILL CONNECTION (SELECT ID FROM information_schema.PROCESSLIST WHERE USER = 'app_user' AND TIME > 300 LIMIT 1);（注意：子查询不能直接嵌套在 KILL 中，需先查 ID 再手动 kill）

监控脚本里该用哪个指标判断“连接异常”

单纯看连接数是否超 max_connections 不够——很多连接是短连、瞬间创建销毁。真正要盯的是 Threads_connected（当前总连接数）与 Threads_running（正在执行非 Sleep 的线程数）的比值。如果 Threads_running 长期接近 0，但 Threads_connected 持续高位，基本就是连接池没复用或没正确 close。

另一个关键信号是 Aborted_connects 和 Aborted_clients 计数器突增，前者代表认证失败（密码错/账号禁用），后者代表客户端异常断开（网络闪断、超时未读结果）。

通过 SHOW GLOBAL STATUS LIKE 'Threads%'; 获取这两个值，不要依赖 information_schema.PROCESSLIST 行数做判断
wait_timeout 和 interactive_timeout 设置过大会让 Sleep 连接滞留更久，调整前需确认应用层是否有长轮询或心跳逻辑
MySQL 8.0+ 可配合 sys.session 视图快速聚合：例如 SELECT user, host, COUNT(*) cnt FROM sys.session GROUP BY user, host HAVING cnt > 50; 找出连接数异常的客户端

实际查连接时，多数人卡在权限和字段含义上。真正麻烦的不是“怎么查”，而是查出来之后，怎么区分哪些是正常心跳、哪些是卡死的僵尸连接——这得结合 Time、State、Info 三列交叉判断，而不是单看数量。