show processlist 是最直接、最低门槛的方式，但看全量需 process 或 super 权限；默认只显示 100 行且 info 截断，可用 show full processlist 或查询 information_schema.processlist 解决；command 与 state 需结合判断连接状态；kill connection 终止连接并回滚事务，kill query 仅中断当前语句。
SHOW PROCESSLIST 是最直接、最低门槛的方式，不需要额外权限就能看到自己发起的连接和语句；但想看全量（尤其是别人在跑什么），必须有 PROCESS 或 SUPER 权限。
为什么 SHOW PROCESSLIST 默认只显示 100 行且 SQL 被截断
MySQL 默认限制输出行数为 100，并对 Info 字段做长度截断（通常 100 字符左右），这是为了防止命令行卡顿或日志爆炸。实际语句可能远长于这个长度，尤其带大量 IN 列表、子查询或 JSON 拼接的 SQL。
解决方法很简单：
- 加
FULL关键字：执行SHOW FULL PROCESSLIST，让Info字段显示完整 SQL - 用
SELECT查表替代：查information_schema.PROCESSLIST，它天然不截断（只要字段值本身没超 MySQL 行限制） - 如果连
FULL都看不到完整内容，说明该连接权限不足——Info为 NULL 或被掩码，此时只能靠关联INNODB_TRX.trx_query或应用层日志反推
怎么区分“真正在跑 SQL”和“只是挂着的空闲连接”
Command 和 State 两个字段必须一起看，单看一个会误判：
-
Command = 'Query'且State = 'Sending data'、'Sorting result'、'Copying to tmp table'：大概率是活跃查询，配合Time > 60基本可定为慢查询 -
Command = 'Query'但State = 'Locked'或'Waiting for table metadata lock'：SQL 已发出去，但卡在锁上，不是执行慢，是阻塞 -
Command = 'Sleep'：连接空闲，等着新请求；但如果Time超过 300 秒，大概率是应用没调close()或连接池泄漏 -
Command = 'Connect'：刚建连还没发任何语句，一般不用管
注意：Time 字段单位是秒，但它表示线程处于当前 Command 状态的时间，不是整条 SQL 的总耗时——比如事务里跑了 3 条语句，Time 只从最后一条开始计。
用 information_schema.PROCESSLIST 做过滤和统计更可靠
命令行交互式查看适合快速扫一眼，但写监控、排查规律性问题，必须用表查询。它的结构化输出能精准过滤、排序、聚合：
- 查所有正在执行的非 Sleep 连接：
SELECT ID, USER, HOST, DB, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 60 - 统计活跃连接数（排除 Sleep）：
SELECT COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND != 'Sleep' - 定位长时间 Sleep 连接来源：
SELECT USER, HOST, COUNT(*) FROM information_schema.PROCESSLIST WHERE COMMAND = 'Sleep' AND TIME > 600 GROUP BY USER, HOST
这个表没有索引，高并发下频繁查（比如每秒轮询）会对 performance_schema 有轻微压力，但日常分钟级轮询完全无感。别用它做实时告警主通道，但用于人工诊断或定时快照足够稳定。
KILL CONNECTION 和 KILL QUERY 容易混淆的点
看到慢查询想终止，先确认你杀的是什么：
-
KILL CONNECTION <code>ID：干掉整个 TCP 连接，包括未提交事务——会触发回滚，日志里记Aborted connection -
KILL QUERY <code>ID：只中断当前正在执行的那条语句，连接保活，事务状态不变（如果之前已 BEGIN 但没 COMMIT，后续还能继续） - 误杀
Command = 'Sleep'的连接，等于白费——它本来就没干活；误杀State = 'Committing'的连接，会导致事务中断，可能丢数据 - 执行
KILL前，务必先用SELECT * FROM information_schema.INNODB_TRX WHERE trx_mysql_thread_id = <code>ID看事务状态，避免在关键提交阶段打断
真正难的不是怎么查，而是查完之后怎么判断哪条该杀、哪条该放、哪条得联系业务方一起看——INFO 字段里的 SQL 本身不带上下文，看不出是不是重试逻辑、补偿任务或导数脚本。
