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

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

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

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

值班现场不要一上来把所有属性导出来。先从当前连接中找出正在占用资源或处于异常状态的线程，记下它的 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 的固定承诺，现场以查询结果为准。

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

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

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 显示的是进程号或实例名，还要回到应用节点的日志和部署信息确认，不要凭字符串猜归属。

查不到属性时，按三种情况收敛

表里没有这条 PROCESSLIST_ID

连接可能已经断开，或者线程 ID 已经不再对应原来的会话。重新执行线程查询并在同一时间窗口读取属性，不要拿旧 ID 继续追。

连接存在但属性为空

客户端可能没有提交连接属性，也可能受连接属性采集开关和权限影响。先确认目标实例的 Performance Schema 配置，再检查驱动连接初始化代码；不要通过修改业务 SQL 来“补”属性。

属性值看起来像旧实例

连接池复用是最常见原因。以当前的 PROCESSLIST_ID、COMMAND、TIME 和 STATE 为准，并到应用侧核对进程或容器实例，而不是只凭一个静态客户端字段下结论。

回滚与告警确认

这套排查只读查询，不需要修改连接或终止线程；如果后续需要处理异常连接，应把终止操作作为单独变更，先记录 ID 和属性快照，再按现有变更流程执行。告警恢复后复查连接总数、活跃线程和同一应用属性值，确认异常实例不再持续建立连接。

复盘时保留哪些证据

至少保留异常时间窗口、PROCESSLIST_ID、ATTR_NAME、ATTR_VALUE、线程状态和应用侧实例标识。这样下次再出现连接数波动，可以区分是连接池扩容、单实例重连，还是某个临时任务没有释放连接。

相关问题

session_connect_attrs 能直接显示应用名称吗？

只有客户端提交了相应属性才可能显示。先看实际的 ATTR_NAME，再判断是否能把它当作应用标识。

为什么同一个应用会出现多组属性？

连接池、驱动版本或不同启动参数都可能造成差异，应按 PROCESSLIST_ID 分组核对，而不是只看一行。

排查的关键是把“线程是谁”和“客户端自报了什么”分开验证：PROCESSLIST_ID 负责连接，session_connect_attrs 负责属性，二者与线程状态对齐后，定位结果才有证据链。