MySQL 正在执行 SQL 如何确认属于哪个连接：线程状态、会话核对与权限边界

订单接口突然从 80 毫秒抖到 4 秒，值班同事最先看到的通常不是完整 SQL，而是一行“某个连接正在执行”。这时先别急着改索引或直接终止会话：要把连接 ID、用户、状态、等待位置和当前语句对上，才能知道后面的判断是否可靠。

先把连接 ID 和现场状态对上

最小核对从进程列表开始。现场不要只复制一段 SQL 文本，因为同一条语句可能同时出现在多个连接里，真正有用的是 Id、User、Host、db、Command、Time、State 和 Info 的组合。

SHOW FULL PROCESSLIST;

一个简化后的结果可能是：

Id    User       Host             db       Command  Time  State                 Info
373   report_ro  10.0.8.21:43102  orders   Query    8     Sending data           SELECT ...
421   api_user   10.0.8.18:39210  orders   Sleep    42                          NULL

这里的 373 就是后续诊断要使用的 connection_id。Sleep 不是慢查询证据，Sending data 也不等于正在通过网络发送大量数据，它只是 MySQL 记录的阶段名，必须结合 SQL、耗时和业务请求继续判断。

为什么还要看 performance_schema.threads

SHOW PROCESSLIST 适合快速看一眼，但长期排查更建议补查 Performance Schema。官方文档说明，threads 表不需要进程列表 mutex，读取对服务器的干扰更小；它还能把线程类型、用户和进程列表字段放在同一行。

SELECT
  THREAD_ID,
  PROCESSLIST_ID AS connection_id,
  PROCESSLIST_USER AS user_name,
  PROCESSLIST_HOST AS host_name,
  PROCESSLIST_DB AS db_name,
  PROCESSLIST_COMMAND AS command_name,
  PROCESSLIST_TIME AS seconds_in_state,
  PROCESSLIST_STATE AS state_name,
  LEFT(PROCESSLIST_INFO, 160) AS sql_text
FROM performance_schema.threads
WHERE PROCESSLIST_ID IS NOT NULL
ORDER BY PROCESSLIST_TIME DESC;

注意两种 ID 不要混用：PROCESSLIST_ID 对应客户端看到的连接 ID，可以拿去执行 KILL 或作为 EXPLAIN FOR CONNECTION 的参数；THREAD_ID 是 Performance Schema 内部线程标识。做日志关联时，建议把两列都记录下来。

会话诊断该怎么选查询入口

当连接 373 仍在运行可解释的查询时，可以从另一个管理员会话执行：

EXPLAIN FORMAT=JSON FOR CONNECTION 373;

它返回的是该连接当前正在使用的计划。因为数据和统计信息可能已经变化，这个结果可能不同于把 SQL 文本复制出来再单独执行 EXPLAIN，这正是它适合排查瞬时问题的地方。若目标连接属于其他用户，除了被解释语句本身所需权限，还需要 PROCESS 权限。

没有 PROCESS 权限时，结果为什么会少

MySQL 的进程列表存在清晰的权限边界。拥有 PROCESS 的账号可以看到所有线程；没有该权限时，普通非匿名账号只能看到自己的线程，匿名账号则看不到线程信息。因此，报表账号查不到应用账号的连接，并不能说明应用没有慢 SQL。

SHOW GRANTS FOR CURRENT_USER();

生产环境不要为了临时排查把高权限账号密码发给开发者。更稳妥的做法是由值班 DBA 在授权会话执行查询，只回传必要的 connection_id、状态和脱敏后的 SQL；若必须建立专用诊断账号，再按团队的最小权限方案审批 PROCESS，并设置有效期。

从观察到处理：四步核对清单

1. 先用 SHOW FULL PROCESSLIST 找到连接 ID，并记录现场时间。
2. 用 performance_schema.threads 复核用户、主机、状态和内部线程映射。
3. 确认连接仍存在且语句可解释，再运行 EXPLAIN FOR CONNECTION connection_id。
4. 只有明确知道业务影响、事务状态和回滚代价时，才考虑 KILL；处理后重新核对请求、锁和错误率。

如果连接在两次查询之间已经结束，拿不到计划是正常现象，不要把空结果当成权限错误。若 PROCESSLIST_INFO 为 NULL，也可能只是连接处于空闲状态，或语句文本不可见；这时先看 Command 与 Time。

常见问题

SHOW PROCESSLIST 里的 Id 和 THREAD_ID 是一回事吗？

不是。Id 是客户端连接标识，THREAD_ID 是 Performance Schema 内部线程标识。跨日志、线程表和计划查询时要明确使用哪一列。

看到 Sleep 很久的连接就应该 KILL 吗？

不应该。连接池会保留空闲连接，先确认它是否持有事务、锁或异常资源，再决定是否处理。

EXPLAIN FOR CONNECTION 为什么有时拿不到结果？

目标语句可能已经结束、正在生成计划，或连接当前并非可解释语句。先重新获取连接 ID 和 State，再做一次短间隔复核。

没有 PROCESS 权限能排查自己的 SQL 吗？

普通非匿名账号通常可以看到自己的线程，但不能据此推断其他用户的连接状态；跨账号排查应由具备相应权限的值班人员完成。

这套流程的核心不是多执行几条查询，而是始终保留“连接 ID—线程状态—当前计划—权限范围”这条证据链。先确认对象，再解释计划，最后才讨论终止或改配置，线上误操作会少很多。