SHOW PROCESSLIST 返回当前时刻正在运行或空闲的客户端连接线程快照，每行含Id、User、Host、db、Command、Time、State、Info字段，其中Info默认截断为100字符。
SHOW PROCESSLIST 返回的是什么数据
show processlist 是 mysql 提供的实时会话快照，不是历史记录，也不是持续流。它只返回当前时刻正在运行（或空闲）的连接线程，每行代表一个客户端连接，包含 id、user、host、db、command、time、state、info 这些字段。其中 info 列最值得关注——它显示该线程正在执行（或最后执行）的 sql 语句，但默认会被截断为 100 字符；如果语句更长，就看不到完整内容。
怎么看到完整的 SQL 语句
直接执行 SHOW PROCESSLIST 看不到长 SQL 的全貌，必须用 SHOW FULL PROCESSLIST。注意是 FULL，不是 full（大小写不敏感，但拼写不能错）。这个命令不会增加开销，只是把 Info 列长度拉到最大（默认 1MB），适合排查被截断的慢查询或动态拼接 SQL。
-
SHOW PROCESSLIST和SHOW FULL PROCESSLIST权限要求一样，都需要PROCESS权限 - 普通用户只能看到自己的线程；只有
SUPER或CONNECTION_ADMIN权限才能看到全部 - 在 MySQL 8.0+ 中，推荐查
performance_schema.threads表，它比SHOW PROCESSLIST更稳定、字段更全，且不受max_allowed_packet影响
为什么有时候查不到正在跑的 SQL
常见原因不是命令没用，而是 SQL 执行太快、已经结束，或者根本没进“执行态”。比如：
- 语句处于
init、starting、checking permissions等初始化阶段，Info可能为空 - SQL 已完成，线程回到
Sleep状态，Info清空，只剩连接信息 - 使用了连接池（如 HikariCP），实际执行的线程和你看到的
Host不一致，真实 SQL 可能在应用日志里 - 开启了
log_slow_verbosity=full但没开long_query_time=0，导致短于阈值的语句不进慢日志，又没卡在PROCESSLIST里
监控时容易忽略的两个细节
一是 Time 字段单位是秒，但它表示的是“当前状态持续时间”，不是 SQL 总耗时。比如一个 State 为 Sending data 的线程，Time=120，说明它卡在这个状态 2 分钟了，未必是整条 SQL 跑了 2 分钟。
二是 State 值本身有误导性：Locked 在 5.7 之后基本不用了，取而代之的是 Waiting for table metadata lock；而 Writing to net 看似快结束了，其实可能因为客户端网络卡住、没读响应，服务端还在等 ACK。
真要长期监控，别靠人工刷 SHOW PROCESSLIST，用 pt-kill 或定时查 information_schema.PROCESSLIST 并过滤 State + Time 组合更靠谱。不过得记住：它只告诉你“此刻谁卡着”，不告诉你“为什么卡”。
