state字段是诊断mysql线程卡点最直接线索，表示线程在执行路径中卡住的具体环节，如“sending data”可能因大结果集扫表或客户端接收慢，“waiting for table metadata lock”多由长事务阻塞ddl导致。
State 字段是诊断 MySQL 线程卡点最直接的线索，不是“正在做什么”的泛泛描述，而是线程在执行路径中卡在哪个具体环节——比如 Sending data 不等于“快结束了”，而可能是大结果集扫表或没走索引；Waiting for table metadata lock 也不是“等一会儿就好”，大概率是 DDL 被长事务阻塞了。
常见 State 值对应的真实瓶颈场景
State 不是状态机枚举，而是执行引擎内部某一步骤的快照。同一 State 在不同上下文里风险等级差异极大：
-
Sleep：连接空闲，正常；但若大量Sleep连接持续数小时，说明应用没正确释放连接（如未 close PreparedStatement），可能耗尽max_connections -
Sending data：正在从存储引擎读取行并发送给客户端。Time 长 ≠ 查询慢，也可能是SELECT *扫了千万行、或客户端接收太慢（比如网络抖动、应用没及时 fetch） -
Sorting for order或Sorting for group：ORDER BY / GROUP BY 触发了文件排序。若sort_buffer_size不够，会写磁盘临时文件，性能断崖下跌 -
Creating tmp table：查询需要临时表（如 DISTINCT、UNION、GROUP BY + 非索引列）。若后续变成Copying to tmp table on disk，说明tmp_table_size或max_heap_table_size设置过小 -
Locked：被表级锁（如LOCK TABLES）或 MyISAM 表阻塞。InnoDB 下极少出现，一旦出现基本可定位为显式锁表语句没释放
高危 State 组合：Time 长 + State 异常
单看 State 容易误判，必须结合 Time 列和 Info 内容交叉验证：
-
State: Waiting for table metadata lock+Time > 30：几乎必有未提交事务（SHOW ENGINE INNODB STATUS查TRANSACTIONS部分），或有人在执行ALTER TABLE卡住了 -
State: Sending data+Info显示简单SELECT但Time > 60：检查是否走了索引（EXPLAIN）、是否被其他慢查询拖累 I/O、或客户端断连后 MySQL 还在发包（net_write_timeout默认 60 秒） -
State: updating或deleting from main table+Time持续增长：UPDATE/DELETE 没走索引，正在全表扫描匹配；或 WHERE 条件涉及函数/类型转换导致索引失效
如何快速定位问题 State 而不被干扰信息淹没
生产环境 SHOW PROCESSLIST 结果常有上百行，优先过滤出真正危险的线程：
- 用
WHERE子句直接筛：SHOW FULL PROCESSLIST WHERE State NOT IN ('Sleep', 'init') AND Time > 5;（跳过空闲和初始化） - 按 State 分组统计频次：
mysql -e "SHOW PROCESSLIST\G" | grep State: | sort | uniq -c | sort -rn，重点关注出现次数多且Time高的 State - 查锁相关 State 时，加
WHERE State LIKE '%lock%'，但注意Waiting for table metadata lock和Locked成因完全不同，不能一概而论 - 如果
Info被截断（默认只显示前 100 字符），务必用SHOW FULL PROCESSLIST，否则可能看不到关键 WHERE 条件
State 是 MySQL 执行链路上的“探针读数”，它不告诉你为什么卡住，只告诉你卡在哪儿。真正的问题往往藏在 State 后面的执行计划、事务状态、或客户端行为里——比如看到 Sorting result，第一反应不该是调大 sort_buffer_size，而是先确认这个 ORDER BY 是否真的必要，或者能否用覆盖索引避免排序。
