当前位置：首页 > 文章列表 > 数据库 > MySQL > MySQL performance_schema 连接属性怎么追踪：借助 session_connect_attrs 定位应用实例

MySQL performance_schema 连接属性怎么追踪：借助 session_connect_attrs 定位应用实例

来源：17golang原创 2026-08-29 13:56:40 0浏览收藏

线上连接数突然升高时，线程列表里的用户和主机往往只能告诉你“谁连进来了”，却不一定能区分订单服务、报表任务和临时脚本。MySQL 的 performance_schema.session_connect_attrs 会保存客户端连接时提交的属性，查询 ATTR_NAME、ATTR_VALUE 与 PROCESSLIST_ID，就能把一条连接还原到驱动、应用实例和线程。

先用 PROCESSLIST_ID 对上连接，再读取 session_connect_attrs 的属性键值；查不到属性时，优先判断客户端是否提交了连接属性，而不是直接认定 MySQL 丢了连接。

实践要点

用 performance_schema.session_connect_attrs 观察客户端连接属性。
用 PROCESSLIST_ID 把属性行和当前线程对应起来。
用 ATTR_NAME、ATTR_VALUE 识别驱动与应用实例，再回到连接状态确认。

连接数升高时，先确认要追踪哪条连接

值班现场不要一上来把所有属性导出来。先从当前连接中找出正在占用资源或处于异常状态的线程，记下它的 PROCESSLIST_ID。这个值是连接属性表和线程视图之间的接点，后面的查询都围绕它展开。

SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO
FROM information_schema.PROCESSLIST
WHERE COMMAND  'Sleep'
ORDER BY TIME DESC;

如果结果中出现长时间执行的查询，先保留 ID，例如 8421。没有异常连接时，也可以选一条来自连接池的活跃连接做验证。

用 session_connect_attrs 把线程还原到应用实例

拿到连接 ID 后，按 PROCESSLIST_ID 查询属性。不同驱动提交的键名可能不同，所以不要只写死某一个应用字段；把属性键值完整展开，才能看出当前客户端到底提供了哪些信息。

SELECT PROCESSLIST_ID, ATTR_NAME, ATTR_VALUE
FROM performance_schema.session_connect_attrs
WHERE PROCESSLIST_ID = 8421
ORDER BY ATTR_NAME;

重点看 ATTR_NAME 和 ATTR_VALUE：前者是属性名，后者是属性值。常见结果会包含驱动或连接器名称、客户端版本、进程标识等线索，但具体键名取决于客户端。这里不要把某个键名当成 MySQL 的固定承诺，现场以查询结果为准。

从 PROCESSLIST_ID 查询 session_connect_attrs 的 MySQL 查询路径示意图

把属性结果和线程状态交叉核对

属性只能说明连接建立时客户端提交了什么，不能单独证明业务实例仍然存活。把属性结果和线程状态放回同一个查询中核对，能避免把已经复用的连接误归给旧实例。

SELECT p.ID, p.USER, p.HOST, p.COMMAND, p.TIME, p.STATE,
       a.ATTR_NAME, a.ATTR_VALUE
FROM information_schema.PROCESSLIST AS p
LEFT JOIN performance_schema.session_connect_attrs AS a
  ON a.PROCESSLIST_ID = p.ID
WHERE p.ID = 8421
ORDER BY a.ATTR_NAME;

看到 COMMAND、TIME、STATE 与属性行属于同一个 ID，才算完成一次可复核定位。若 ATTR_VALUE 显示的是进程号或实例名，还要回到应用节点的日志和部署信息确认，不要凭字符串猜归属。