相较于Command，State列能够更为精准地反映查询的真实执行阶段。比如，Waiting for table metadata lock意味着被DDL阻塞，而Sending data可能在扫描或网络传输环节出现卡顿。要判断是否真的卡住，需结合Time和Command。同时，要留意Binlog Dump线程Time的不同含义。为避免因SQL截断而产生误判，可使用SHOW FULL PROCESSLIST。此外，还需结合Host、User等上下文信息来定位根本原因。
看 State 列识别真实执行阶段
State 比 Command 更能反映查询当前卡在哪一步。比如 Command 是 Query，但 State 是 Waiting for table metadata lock，说明它根本没开始执行 SQL，而是被另一个 DDL（如 ALTER TABLE）阻塞了；又比如 State 是 Sending data，不代表快结束了——它可能正在扫描千万行后逐条发给客户端，也可能刚查完就卡在网路传输上。
常见关键 State 含义：
statistics：正在计算索引统计信息，常出现在刚 ANALYZE TABLE 或首次访问大表时Sorting result：结果集正在内存或磁盘排序（ORDER BY/DISTINCT/GROUP BY）Copying to tmp table：中间结果写入临时表，通常意味着复杂 JOIN 或子查询未走索引Locked：老版本 MySQL 中表级锁等待，现在少见；若出现，优先检查是否用了 MyISAMNULL：查询已结束，线程正准备关闭连接（此时Time可能还在涨，别误杀）
结合 Time 和 Command 判断是否真卡住
Time 是秒级计数，但它从“进入该状态”开始算，不是从查询发起开始。所以一个 Command = Sleep、Time = 3600 的线程只是空闲连接，不是问题；而 Command = Query、Time > 30 就值得盯住——尤其当 State 是 Updating 或 Writing to net 时。
注意陷阱：
Time对于Binlog Dump线程意义不同：它表示主从复制延迟秒数，不是查询耗时- 某些
State（如init）持续时间极短，Time = 0是正常的，不用紧张 - 如果
Info为空但Command = Query、State = executing，可能是权限不足导致无法读取语句内容（需PROCESS权限）
用 SHOW FULL PROCESSLIST 防止误判截断语句
默认 SHOW PROCESSLIST 的 Info 列只显示前 100 字符，对长 SQL（比如带几十个 JOIN 或嵌套子查询的报表语句）极易误判。例如你看到 Info 是 SELECT a.id, a.name FROM user a LEFT JOIN ...，以为是简单关联，实际后面还有 5 层嵌套和 UNION ALL —— 这种必须加 FULL：
SHOW FULL PROCESSLIST WHERE Time > 60;
另外，SHOW FULL PROCESSLISTG 在命令行里更实用：每列独占一行，方便用 grep 或 awk 提取特定字段，比如快速统计各状态分布：
mysql -e "SHOW FULL PROCESSLISTG" | grep "^State:" | sort | uniq -c | sort -rn
别忽略 Host 和 User 的上下文线索
仅看一条慢线程是不够的，得结合来源去定位根本原因。例如，当看到User = 'app_user'、Host = '10.20.30.40:54321'，马上就能对应到某台应用服务器上的某个服务实例；而要是出现User = 'replication'、Host = 'xxx:33061'，那就是主从同步线程，State = Waiting for master to send event这种情况属于正常等待。
容易被忽视的点：
- 同一个
User出现大量Time接近的Query线程，大概率是应用端连接池配置不当（如未启用连接复用、超时设置过长） Host显示localhost但db为空，往往是监控脚本或定时任务连上来只执行SHOW PROCESSLIST自身，不是业务问题- 若
db列大量为NULL，说明很多连接没指定默认库，后续所有查询都得带database.table全限定名，增加解析开销
真正难的不是看出哪个线程慢，而是区分它是“暂时卡住”还是“永远卡住”——这需要把 State、Time、Info 和外部上下文（比如是否有 DDL 正在跑、磁盘 I/O 是否打满、网络是否丢包）拼起来看。单独盯着一行输出做决定，八成会 kill 错。
