用 SHOW PROCESSLIST 查正在运行的 SQL 最直接，可查看连接 ID、用户、主机、数据库、命令、时间、状态及 SQL 内容；需关注 Command 为 Query 且 State 非 Sleep 才是真执行中。
怎么查正在跑的 SQL？用 SHOW PROCESSLIST 最直接
MySQL 自带的 SHOW PROCESSLIST 就是看当前活跃连接和执行语句的入口，不需要额外权限（只要不是 SUPER 权限受限用户），也不依赖第三方工具。
执行后能看到每个连接的 ID、User、Host、db、Command、Time、State 和最重要的 Info 字段——那里面就是实际在跑的 SQL。
-
Command是Query才代表真正在执行 SQL；Sleep是空闲连接，Connect是刚建立还没发请求 -
State为Sending data或Copying to tmp table时，SQL 可能已卡住，别只盯着Info看内容，得结合状态判断 - 默认只显示前 100 行，加
FULL参数可看到完整 SQL：SHOW FULL PROCESSLIST
为什么 INFORMATION_SCHEMA.PROCESSLIST 更适合写监控脚本？
相比命令行交互式查看，脚本或告警系统需要结构化数据，INFORMATION_SCHEMA.PROCESSLIST 提供标准表接口，支持 WHERE 过滤、ORDER BY 排序、定时轮询。
比如查运行超 60 秒的查询：SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE TIME > 60 AND COMMAND = 'Query'。
-
TIME单位是秒，但注意：它表示该线程处于当前Command状态的时间，不等于 SQL 总耗时 -
INFO字段可能为NULL（比如权限不足或 SQL 已结束但连接未关闭），不能假设一定有值 - 该表不记录已断开的连接，也不包含被
KILL后尚未退出的残留线程
KILL 之前必须确认什么？别误杀连接
查到慢 SQL 想终止，用 KILL <code>ID 很快，但风险在于：ID 对应的是连接线程，不是某条 SQL。一个连接里可能已执行完几条语句，当前只是空闲；也可能正处在事务中间，KILL 会回滚未提交的变更。
- 先看
State：如果是Locked或Waiting for table metadata lock，KILL 可能缓解阻塞；但若为Committing，KILL 会导致事务中断，日志里会出现Aborted connection - 用
KILL QUERY <code>ID只中断当前语句，保留连接，适合不想断开客户端的场景 -
ID不是自增主键，重启 MySQL 后会重置，别存成持久 ID 做关联
为什么有些 SQL 在 PROCESSLIST 里看不到？
不是所有 SQL 都会出现在这里，常见原因有三个：
- SQL 执行太快，
SHOW PROCESSLIST是快照，可能刚好错过；这类短查询更适合用slow_query_log或性能模式（performance_schema）捕获 - 用户权限不足，
PROCESSLIST默认只显示自己用户的连接，需PROCESS权限才能看全部 - 启用了
performance_schema且配置了events_statements_current，但没开采集开关（如setup_consumers中events_statements_current为NO），这时也查不到
真正难定位的，往往是那些不常出现、但每次出现就拖垮数据库的“幽灵查询”——它们可能来自定时任务、ORM 自动生成的隐式 JOIN，或者应用层连接池复用后遗留的未关闭事务。这时候光盯 PROCESSLIST 不够，得配合 general_log 或慢日志分析器一起看。
