SHOW PROCESSLIST 是什么
SHOW PROCESSLIST 把实例当前每个连接列成一行：谁在连、从哪来、连着哪个库、正在跑什么语句、这个状态持续了多久。它是 MySQL 里最轻量的实时活动视图，8.0 的数据来源是 performance_schema 的线程表，information_schema.processlist 提供同一份数据的可查询版本。定位连接堆积、长事务、元数据锁等待、Sleep 连接泄漏，通常都从这张清单开始。
基本信息
| 用途 | 会话与运行中语句的实时排查 |
|---|---|
| 语法 | SHOW [FULL] PROCESSLIST |
| 可查询版本 | information_schema.processlist |
| 关键字段 | Id / User / Host / db / Command / Time / State / Info |
| 权限要求 | 普通账号只见自己线程，全量查看需要 PROCESS |
| 处置配套 | KILL QUERY 结束语句，KILL CONNECTION 断开连接 |
典型使用场景
- 页面大面积卡顿：确认是否有长事务占着行锁，或有语句停在 Sending data 阶段
- 连接数触顶报 Too many connections：区分是连接池泄漏还是一次性慢语句堆积
- DDL 卡住不动：ALTER 处于等待元数据锁状态时，找出是谁握着那张表
- 从库上确认复制线程是否还在：system user 线程代表 IO 与 SQL 线程的存活情况
- 确认备份任务是否仍在跑：mysqldump、xtrabackup 会留下长时间运行的会话
- 准备终止会话前的取证：记录 Id、账号、持续时长与完整语句，便于复盘
基础用法
基础用法
SHOW FULL PROCESSLIST; # 完整语句，Info 列不截断
SELECT id, user, host, db, command, time, state, LEFT(info,60) AS sql_head
FROM information_schema.processlist
WHERE command <> 'Sleep'
ORDER BY time DESC LIMIT 20; # 按耗时排序看活跃语句
SELECT user, command, COUNT(*) AS conns
FROM information_schema.processlist
GROUP BY user, command
ORDER BY conns DESC; # 按账号统计连接，定位泄漏来源
KILL QUERY 12345; # 只结束当前语句，连接保留
KILL CONNECTION 12345; # 连接一并断开，未提交事务回滚字段逐列读法
| 列 | 含义 | 异常信号 |
|---|---|---|
| Id | 连接线程号，也是 KILL 的句柄 | 记录 Id 再处置，避免杀错会话 |
| User | 登录账号 | system user 多为复制与内部线程，属正常 |
| Host | 来源地址与端口 | 来源高度集中说明复用同一连接池 |
| db | 当前默认库，未选库为 NULL | 结合 SQL 判断是否连错了库 |
| Command | Sleep / Query / Binlog Dump 等 | 大量 Sleep 说明连接未有效复用 |
| Time | 当前状态已持续的秒数 | Sleep 很久正常；查询的 Time 很大即为慢语句 |
| State | 细粒度阶段 | 等待元数据锁、Sending data、Locked 都是常见卡点 |
| Info | 正在执行的语句 | 默认截断一百字符，要看全用 FULL |
二次确认与配套查询
二次确认与配套查询
SHOW FULL PROCESSLIST; # 间隔五到十秒再执行一次，Time 递增且语句未变才是真卡住
SELECT trx_id, trx_state, trx_started, trx_rows_modified, trx_mysql_thread_id
FROM information_schema.innodb_trx
ORDER BY trx_started; # 长事务视角，配合 Id 定位持有者
SELECT COUNT(*) FROM information_schema.processlist; # 与 max_connections 对比看水位
SHOW VARIABLES LIKE 'max_connections'; # 确认连接上限，评估是否需扩容或收敛连接池SHOW PROCESSLIST 的可见范围受权限约束：没有 PROCESS 权限的账号只能看到自己的线程，排查时容易得出没有慢查询的错误结论，用有权限的账号或从监控侧采集。
从库上出现 system user 且 Command 为 Query 或 Binlog Dump 的线程，是复制 IO 线程与 SQL 线程在工作的表现，不要把它们当异常连接清掉，否则主从同步立刻中断。
KILL 一个正在执行的大事务会先进入回滚，回滚耗时可能与事务本身运行时长同量级，期间仍占用锁与资源，业务高峰期动手前先评估影响面。
连接异常的常见成因
- 连接池上限配置过大，同一批应用抢占会话，其他业务拿不到连接
- 应用异常退出未关闭连接，Sleep 会话缓慢累积直到触顶
- 长事务或未提交事务一直挂着，占住会话并长期持有锁
- 慢语句并发叠加，等待中的会话把活跃连接数推高
- 监控或巡检程序连接后没有正确关闭，形成稳定的泄漏速率