show full processlist完整显示所有线程的sql语句（info列不截断），需process权限才能查看全部连接；其state反映线程内部状态，info仅显示最后执行语句而非实时运行语句，kill后command变killed表示信号已接收。
SHOW FULL PROCESSLIST 能看到什么
它列出所有当前连接的线程，关键区别在于 SHOW FULL PROCESSLIST 不会截断 Info 列——也就是正在执行的 SQL 语句会完整显示，而普通 SHOW PROCESSLIST 默认只显示前 100 字符左右。这对分析长查询、带大量参数的 INSERT/UPDATE 或动态拼接 SQL 尤其重要。
权限不够时只能看到自己的进程
普通用户执行 SHOW FULL PROCESSLIST 只能看到自己发起的连接；要查看全部线程，必须拥有 PROCESS 权限（通常只有管理员或 DBA 拥有）。如果你发现结果只有 1–2 行，且 User 列和你登录的账号一致，大概率是权限受限。
- 确认权限：执行
SELECT CURRENT_USER();和SHOW GRANTS;查看是否包含GRANT PROCESS ON *.* - 替代方案：用
SELECT * FROM information_schema.PROCESSLIST;—— 同样受权限控制，但可配合WHERE筛选，比如WHERE COMMAND = 'Query' AND TIME > 30 - 注意：即使有权限，某些 MySQL 配置（如
show_compatibility_56 = ON）可能影响列名大小写或字段可见性
State 和 Info 字段经常被误读
State 是线程内部状态，不是 SQL 执行阶段；Info 是最后一条执行语句，不等于“当前正在跑的语句”——尤其在事务中，它可能停留在 BEGIN 之后的第一条 UPDATE，而后续几十条已执行完但未提交。
-
State = 'Sending data'并不单指 SELECT 返回结果，UPDATE/DELETE 扫描行、INSERT 写入缓冲区也常卡在这里 -
Info为空或为NULL很常见：事务刚开启、锁等待中、或客户端使用预编译语句（如 JDBC 的PreparedStatement）时，真实 SQL 不会回填到该字段 - 长时间
State = 'Locked'且Info显示的是简单语句（如UPDATE t SET x=1 WHERE id=123），基本可判定是行锁或元数据锁（MDL）冲突，不是语句本身慢
KILL 之后没反应？先看 COMMAND 是否变成 Killed
执行 KILL <code>id 后线程没立刻消失，不代表失败。MySQL 会在安全点响应中断信号，而以下场景会让线程“挂住”几秒甚至更久：
- 正在刷脏页（InnoDB buffer pool flush）
- 处于两阶段提交的
Committing状态（尤其是 binlog + redo 同步阶段） - 持有表锁或全局读锁（
FLUSH TABLES WITH READ LOCK） - 等待磁盘 I/O（如读取大 BLOB、临时表落盘）
此时查 information_schema.PROCESSLIST，如果 Command 列已变为 Killed，说明信号已接收，只需等待；若仍是 Query，需检查是否存在锁等待链，用 performance_schema.data_lock_waits（MySQL 8.0+）定位阻塞源头。
