• init：线程刚刚启动，还在初始化，尚未开始处理 SQL 语句。
• updating：正在执行 UPDATE 或 DELETE 操作，但还没深入到存储引擎层（比如还在解析条件）。
• Writing to net：查询结果集已经准备就绪，正被拷贝到客户端的 socket 写缓冲区里。
• Creating sort index：当 ORDER BY 或 GROUP BY 无法利用现有索引时，MySQL 会为排序结果在内存或磁盘上构建一个临时索引。

为什么 root 用户也看不到全部连接，而 show full processlist 还是被截断

这其实不是权限问题，而是 MySQL 的默认设计使然。标准的 show processlist 命令会对结果进行字段截断，尤其是 Info 列，通常只显示前 100 个字符。一旦 SQL 语句超长，后半部分就直接被“腰斩”了，这确实让人头疼。

那么，到底怎样才能看到完整的 SQL 呢？可靠的方法主要有两个：

• 使用 show full processlist 命令。不过，部分客户端工具（如 MySQL Shell）会自动展开完整信息，而其他工具可能需要你手动复制 Info 字段才能看到全貌。
• 直接查询性能视图：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM performance_schema.threads WHERE TYPE = 'FOREGROUND' AND INFO IS NOT NULL。这里的 INFO 字段是完整的，但前提是确保 performance_schema 功能已启用，并且相关的消费者（如 events_statements_current）已经打开。

另外提个醒，即便是拥有 process_priv 权限的非 SUPER 用户，默认也只能查看自己的线程。有些系统级别的线程（比如复制 IO 线程，属于 SYSTEM_USER 类型），普通权限是看不到的。

kill 掉一个卡住的查询，为什么有时没反应

执行 KILL 后查询没有立即消失，这通常不代表命令失败了，而是目标线程正卡在某个“不可中断”的点上。常见的情况包括：

• 线程正在等待磁盘 I/O 操作完成，比如刷写脏页或者读取大型 BLOB 字段。
• 线程持有 InnoDB 的行锁或表锁，而其他事务正在等待它释放这些锁。
• 线程正处于 Committing 阶段，特别是在进行 binlog 和 redo log 双写提交的关键时刻。
• 查询被全局锁（如 FLUSH TABLES WITH READ LOCK）阻塞，此时 KILL 命令也会被挂起，直到全局锁释放。

遇到这种情况，可以先查询 information_schema.PROCESSLIST，看看该线程的 COMMAND 是否已经变成了 Killed。如果显示还是 Query，说明终止信号还没被响应，可能需要耐心等待几秒，或者进一步检查是否存在锁冲突（可以借助 SELECT * FROM performance_schema.data_locks 来辅助分析）。

如何持续监控长执行查询而不漏掉瞬间慢 SQL

show processlist 只是一个瞬间快照，对于那些毫秒级闪现却又影响巨大的“瞬间慢查询”，它根本无能为力。要捕获这些“幽灵”，你必须依赖更持续的监控手段：

• 开启慢查询日志：通过 SET GLOBAL slow_query_log = ON 启用，并将 long_query_time 设置为 0，可以记录所有执行过的语句（需要注意由此带来的磁盘空间和性能开销）。
• 利用 performance_schema.events_statements_history_long 表，它可以查询到最近执行的 10000 条语句记录（使用前需确保已开启对应的消费者功能）。
• 通过脚本定期轮询 SHOW PROCESSLIST，并过滤出 TIME > 60 的长时间运行查询。但这种方法要谨慎，避免过于频繁的查询反而给系统增加额外负载。

最后记住一点：千万别只依赖单次的 show processlist 来判断数据库的整体健康状况。它只能告诉你“此刻谁在线上”，却无法揭示“过去究竟发生了什么”。真正的问题根源，往往隐藏在历史执行时间的分布曲线之中。