SHOW FULL PROCESSLIST可查看完整SQL，但需PROCESS权限且Info为NULL时说明线程未执行语句；information_schema.PROCESSLIST支持SQL过滤但受相同截断和权限限制；KILL不立即生效，Locked等状态需先解除MDL阻塞；performance_schema提供细粒度执行上下文但需提前启用消费者。
直接用 SHOW FULL PROCESSLIST，但得先确认权限和截断问题——它不是万能的，也不是所有场景都适用。
为什么 SHOW PROCESSLIST 看不到完整 SQL？
默认只显示 Info 字段前 100 个字符，长查询必然被截断。这不是 bug，是 MySQL 的硬性限制。
- 必须用
SHOW FULL PROCESSLIST才能突破 100 字符限制 - 需要
PROCESS权限；普通账号即使连上也看不到别人会话，root在 MySQL 8.0+ 也得显式授权：GRANT PROCESS ON *.* TO 'root'@'%' - 如果
Info列仍是NULL，说明线程当前没在执行语句（比如处于Sleep、Locked或 I/O 等待中）
information_schema.PROCESSLIST 能做什么？
它本质是 SHOW PROCESSLIST 的底层视图，好处是可以加 WHERE 过滤、ORDER BY 排序，适合写监控脚本或排查特定问题。
- 查所有活跃查询：
SELECT ID, USER, HOST, DB, TIME, STATE, INFO FROM information_schema.PROCESSLIST WHERE COMMAND = 'Query' AND INFO IS NOT NULL ORDER BY TIME DESC - 注意：该表不支持
FULL模式，字段长度限制和SHOW PROCESSLIST一致，仍需配合SHOW FULL PROCESSLIST看完整语句 - 权限同上，无
PROCESS权限时只能查到自己的行
为什么 KILL 不生效？常见卡点在哪？
KILL 不等于“立即终止”，它只是发中断信号，线程是否响应取决于当前状态。
-
State是Locked或Waiting for table flush：大概率被 DDL（如ALTER TABLE）阻塞，持有元数据锁（MDL），此时KILL无效，得先查并干掉 MDL 持有者 -
State是Sending data或Copying to tmp table：说明语句正在执行中，KILL会等它自然退出，可能耗时数秒甚至更久 - 安全做法：先用
SELECT * FROM performance_schema.threads WHERE PROCESSLIST_ID = ?查线程详情，再联查events_statements_current确认最后执行语句
想看更细粒度的执行上下文，该用 performance_schema
SHOW PROCESSLIST 是快照，而 performance_schema 能看到等待事件、资源消耗、历史执行轨迹——但要提前开启对应消费者。
- 查当前执行中的完整语句：
SELECT THREAD_ID, PROCESSLIST_USER, PROCESSLIST_INFO, STATE, WORK_COMPLETED FROM performance_schema.threads t JOIN performance_schema.events_statements_current e USING (THREAD_ID) WHERE t.PROCESSLIST_STATE = 'Executing' - 必须确保启用：
UPDATE performance_schema.setup_consumers SET ENABLED = 'YES' WHERE NAME IN ('events_statements_current', 'events_waits_current') - 默认 MySQL 5.6+ 已启用
performance_schema，但相关 consumer 可能关闭，不检查就查不到数据
真正难的不是“怎么查”，而是判断查出来的 State 和 Time 到底意味着什么——比如 Writing to net 是网络慢，Creating sort index 是内存不足，这些状态背后没有统一文档，得结合经验交叉验证。
