SHOW PROCESSLIST显示的是当前用户可见的连接快照，关键字段包括Id、User、Host、State；需PROCESS权限加ALL才可见全部连接，root也需显式授权，推荐用performance_schema.threads替代。
直接看 SHOW PROCESSLIST 就能拿到当前活跃 SQL，但默认只显示前 100 行、截断长语句、且权限受限时看不到别人连接——别急着复制粘贴，先确认你看到的是真正在跑的，不是 Sleep 线程。
为什么 SHOW PROCESSLIST 显示的 SQL 经常不完整或为 NULL
MySQL 默认限制 INFO 字段长度（约 100 字符），超长 SQL 会被截断；更关键的是，INFO 为 NULL 并不等于没在执行，常见于：
— 权限不足：普通用户只能看到自己发起的连接，PROCESS 权限缺失时其他线程的 INFO 强制设为 NULL
— 状态切换中：SQL 执行完但连接未关闭，COMMAND 可能已变回 Sleep，INFO 清空
— 使用了预编译语句（PREPARE/EXECUTE）：部分版本中 INFO 不回填实际 SQL
解决办法：加 FULL 参数看完整语句：SHOW FULL PROCESSLIST；若仍为空，换 INFORMATION_SCHEMA.PROCESSLIST 表查，它对权限和截断更可控。
INFORMATION_SCHEMA.PROCESSLIST 怎么过滤出真正在执行的慢查询
这个表本质是视图，支持标准 SQL 过滤，比命令行更适合写监控脚本或告警逻辑：
— 关键条件必须同时满足：COMMAND = 'Query'（排除 Sleep/Connect）且 STATE NOT IN ('Sleep', 'Init')（排除空闲或初始化状态）
— 判断是否“慢”：用 TIME > 60，注意单位是秒，且是当前命令持续时间，不是 SQL 总耗时
— 示例语句：SELECT ID, USER, HOST, DB, TIME, STATE, INFO FROM INFORMATION_SCHEMA.PROCESSLIST WHERE COMMAND = 'Query' AND TIME > 60 AND INFO IS NOT NULL ORDER BY TIME DESC LIMIT 10
— 注意：INFO 仍可能为 NULL，所以不能用 WHERE INFO != '' 替代 IS NOT NULL；另外该表不包含被 KILL 后尚未退出的残留线程。
用 KILL 终止 SQL 时最易踩的三个坑
KILL 操作对象是连接线程，不是某条 SQL 本身，误操作会导致事务中断或连接意外断开：
— 直接 KILL <code>ID 会干掉整个连接，如果线程正处于事务中（STATE = 'Committing' 或 'Locked'），未提交变更将回滚，日志里出现 Aborted connection
— 正确做法是优先用 KILL QUERY <code>ID，它只中断当前语句，保留连接，适合 Web 应用等不想重连的场景
— ID 不是持久标识：MySQL 重启后重置，不要存成配置项长期引用；查到可疑线程后，务必先 SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST WHERE ID = <code>ID 再确认状态和 SQL 内容，避免杀错
— 特别注意 STATE = 'Waiting for table metadata lock'：这类阻塞通常要先 KILL 掉持有锁的线程，而不是等锁的线程。
真正难的不是查到 SQL，而是判断它为什么卡住——STATE 字段比 INFO 更值得盯紧，比如 Sending data 可能是结果集太大，Copying to tmp table 往往意味着排序或分组没走索引，这些信号比 SQL 文本本身更能定位根因。
