state列比command更能准确反映查询真实执行阶段，如waiting for table metadata lock表示被ddl阻塞，sending data可能卡在扫描或网络传输；结合time和command判断是否真卡住，注意binlog dump线程time含义不同；用show full processlist避免sql截断误判；需结合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 中表级锁等待，现在少见；若出现，优先检查是否用了 MyISAM -
NULL：查询已结束，线程正准备关闭连接（此时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 PROCESSLIST\G 在命令行里更实用：每列独占一行，方便用 grep 或 awk 提取特定字段，比如快速统计各状态分布：
mysql -e "SHOW FULL PROCESSLIST\G" | 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 错。
