服务器客户端正在执行processlist是什么意思？show processlist命令详解

服务器客户端在做 processlist，本质是读取 MySQL 当前所有连接线程的运行状态，用于快速判断连接堆积、慢 SQL 与锁冲突。 学会读 processlist，是 DBA 从“被动救火”转向“主动排障”的第一道分水岭。

processlist 是什么：数据库的实时监控摄像头

SHOW PROCESSLIST 是 MySQL 提供的一项实时会话查看命令，它把每条客户端连接当作一个线程，记录线程当前正在做什么、做了多久、卡在哪个环节，这份 MySQL processlist 命令详解，重点在于字段与 State 判断，而不是简单看 SQL 文本。

1 核心字段解读

执行 SHOW FULL PROCESSLIST 后，常见字段如下：

2 为什么要用 FULL

普通 SHOW PROCESSLIST 会截断 Info 字段。 生产排查必须优先使用 SHOW FULL PROCESSLIST，否则大量复杂 SQL 只显示前 100 个字符，容易漏掉关键表名与条件。

做 processlist 时的三大高频异常场景

1 连接数堆积：服务器客户端连接数过多怎么办

这是最常见的告警场景。服务器客户端连接数过多怎么办？先看 Command 列。

• 大量 Sleep 且 Time 很高：应用连接池未复用连接，或程序未正确关闭连接。
• 大量 Query 且 Time 相近：可能是突发流量打满执行队列。
• 连接数逼近 max_connections：新连接被拒绝，业务直接报错。

处理顺序：

1. 识别 Sleep 比例：若超过 60%，先收紧应用连接池。
2. 调低 wait_timeout：从 28800 秒调整到 300-600 秒，让空闲连接及时释放。
3. 开启线程池：MySQL 企业版或 Percona Server 可启用 Thread Pool，降低高并发下的线程切换开销。

2 长时间 Running 的 Query：数据库 processlist 卡顿原因

数据库 processlist 卡顿原因里，九成是 SQL 执行计划变化或数据量增长。

典型 State：

• Sending data：正在读取或扫描数据，Time 超过 10 秒，通常意味着回表行数过大。
• Copying to tmp table：查询触发磁盘临时表，常见于 ORDER BY、GROUP BY 未走索引。
• Sorting result：排序缓冲区不够或排序列无索引。

这些状态本身不是错误,但时间维度才是判断标准，同一个 Sending data，Time 为 0 秒是正常读取，Time 为 60 秒就是事故前兆。

3 锁等待：Waiting for table metadata lock

DDL 与 DML 互锁在线上极容易出现。北京服务器运维 processlist 的交流群中，经常看到这样的画面：

• 一条 ALTER TABLE ... ADD COLUMN 处于 Waiting for table metadata lock。
• 后面几十条业务 UPDATE 全部排队。
• 原因是有未提交事务持有该表的元数据锁。

处理方法：

• 用 SELECT * FROM sys.schema_table_lock_waits 找出阻塞源会话。
• 结束阻塞源对应的未提交事务。
• 上线 DDL 前，检查 information_schema.innodb_trx 中是否有长事务。

实战：一次生产环境 processlist 排障复盘

某电商系统大促期间,数据库 CPU 突然从 35% 飙升到 92%，订单接口响应时间超过 5 秒。

操作步骤：

1. 登录主库,执行 SHOW FULL PROCESSLIST。
2. 发现 40 条相同模式的查询：SELECT * FROM orders WHERE user_id = ? AND status = ?。
3. State 全部为 Sending data，Time 平均 35 秒。
4. 检查索引后发现,新上线的营销活动增加了 status 条件，但原索引只有 user_id 单列。
5. 处理动作：先 KILL 掉 Time 超过 20 秒的会话，再添加 (user_id, status) 联合索引。
6. 五分钟后,数据库 CPU 回落到 42%，接口恢复正常。

1 高频 State 与对应动作

2 现场命令操作顺序

• SHOW FULL PROCESSLIST; 抓取全部线程。
• SELECT * FROM performance_schema.threads WHERE PROCESSLIST_STATE IS NOT NULL; 获取更细状态。
• KILL <Id>; 结束异常连接。
• EXPLAIN <SQL>; 分析执行计划。

processlist 和慢查询对比：谁的定位能力更强

processlist 和慢查询对比，本质是“实时监控”与“事后审计”的关系。

1 最佳组合策略

• 平时通过慢查询日志发现“问题 SQL 清单”。
• 线上出现卡顿时,用 processlist 定位“此刻谁在拖后腿”。
• 结合 performance_schema.events_statements_current，可以保留最近执行完的语句，弥补 processlist 历史缺失的问题。

2026 年 processlist 优化与替代方案

1 官方新能力

MySQL 8.0 之后，performance_schema.threads 表功能已经涵盖 processlist，并且支持条件过滤，2026 年主流生产版本为 MySQL 8.4 LTS，其 sys.session 视图比原始 processlist 更易读。

推荐替代视图：

• sys.session：当前会话精简信息。
• sys.schema_table_lock_waits：表锁等待链路。
• sys.innodb_lock_waits：InnoDB 行锁等待。
• performance_schema.events_statements_current：最近执行语句。

2 参数与基线建议

• wait_timeout：建议 300-600 秒，杜绝大量陈旧 Sleep。
• interactive_timeout：批量任务适度放大，但不超过 1800 秒。
• max_connections：按内存与 CPU 评估，避免 OOM。
• thread_cache_size：设置为 8-16，减少线程频繁创建销毁。

服务器客户端在做 processlist，不是简单敲一条命令，而是在读一张数据库实时运行地图，字段、State、Time 三者配合，能快速锁定大部分连接堆积、慢 SQL 和锁冲突，掌握 processlist 的深度读法，平均排障时间可以从 30 分钟压缩到 5 分钟。

问答模块

问：MySQL processlist 中 State 显示 Sending data 代表查询卡了吗？

答：不一定。Sending data 是查询读取数据阶段，短时间出现属于正常。Time 持续超过 10 秒，且 Info 中的 SQL 涉及大表或缺失索引，才需要介入分析。

问：processlist 和 show full processlist 有什么区别？

答：普通 SHOW PROCESSLIST 会截断 Info 字段，通常只显示前 100 个字符。SHOW FULL PROCESSLIST 显示完整 SQL 文本，生产排查必须使用 FULL 版本，否则容易漏掉关键过滤条件。

问：日常巡检发现大量 Sleep 连接正常吗？

答：短时 Sleep 可以接受，若 Time 超过 300 秒且数量占连接总数 60% 以上，说明连接未复用或应用未关闭连接，应检查连接池配置和 wait_timeout。

你在 processlist 中遇到过最棘手的 State 是什么？欢迎结合实际场景继续拆解。

参考文献

1. Oracle Corporation，MySQL 8.0 Reference Manual，2025年，《SHOW PROCESSLIST Statement》。
2. Baron Schwartz 等，《高性能MySQL（第4版）》，2022年，第3章 服务器性能剖析。
3. 阿里云,RDS MySQL 性能优化白皮书，2025年，连接管理与线程池章节。
4. Percona Blog，Using SHOW PROCESSLIST to Diagnose MySQL Performance Issues，2024年。

小伙伴们，上文介绍服务器客户端在做_processlist的内容，你了解清楚吗？希望对你有所帮助，任何问题可以给我留言，让我们下期再见吧。