SHOW PROCESSLIST 返回当前MySQL所有线程的快照，每行含ID、User、Host、db、Command、Time、State、Info字段；普通用户仅见自身会话，需PROCESS权限或查information_schema.PROCESSLIST才能看全量。
SHOW PROCESSLIST 返回的是什么数据
它直接列出 MySQL 当前所有线程（即客户端连接）的快照，每行代表一个会话，包含 ID、User、Host、db、Command、Time、State、Info 这些关键字段。其中 Info 是实际执行的 SQL（可能被截断），State 表示线程当前在做什么（比如 Sending data、Locked、Waiting for table metadata lock），比 Command 更细粒度。
普通用户执行 SHOW PROCESSLIST 只能看到自己的会话
这是权限控制导致的常见困惑：没给 PROCESS 权限的账号，运行 SHOW PROCESSLIST 只返回自己发起的连接，哪怕有上百个活跃连接也看不到别的。要查全量，必须满足以下任一条件：
- 用
root或拥有PROCESS权限的账号登录 - 改用
SELECT * FROM information_schema.PROCESSLIST（同样受权限限制，但可配合WHERE过滤，比如查某个库的会话：WHERE DB = 'myapp'） - MySQL 5.7+ 中，启用 performance_schema 后可通过
performance_schema.threads查更详细线程状态（需提前开启相关 consumer）
长时间 Sleep 状态不等于“没用”，但可能是连接泄漏信号
Command 为 Sleep、Time 值很大（比如 > 300 秒）的会话，常被误认为“闲置可杀”。实际上这取决于应用连接池配置：
- 如果用的是 HikariCP、Druid 等主流连接池，默认
maxLifetime和idleTimeout通常设为几十分钟，Sleep 几百秒完全正常 - 但如果同一应用反复新建连接却不释放（比如没 close
Connection），就会看到大量低Time值的 Sleep 会话持续增长——这才是泄漏迹象 -
Kill前务必确认来源：Host字段能看出是哪个服务 IP，Info为空且Time极长的，大概率是空闲连接；而Info有 SQL 且State卡在Updating或Writing to net的，可能是慢查询或网络卡顿
SHOW FULL PROCESSLIST 才能看到完整 SQL
默认 SHOW PROCESSLIST 对 Info 字段只显示前 100 字符，复杂 SQL 或带长参数的查询会被截断，看不出真正执行内容。必须加 FULL 关键字：
SHOW FULL PROCESSLIST;
注意两点：
-
FULL不是独立命令，不能写成SHOW PROCESSLIST FULL，顺序错就报语法错误 - 即使加了
FULL，MySQL 仍可能因内部缓冲限制截断极长 SQL（如动态拼接的千万级 IN 查询），此时得结合general_log或slow_query_log追溯
真正难的不是看到会话，而是判断哪个该杀、哪个该调、哪个其实只是暂时卡在网络栈里。State 和 Time 组合看，比单看 Command 可靠得多。
