如何在Navicat中查看当前全部活跃数据库连接的会话详情

作者：袖梨 2026-07-20

<p>Navicat中查看MySQL活跃会话需执行SELECT * FROM information_schema.PROCESSLIST（无需PROCESS权限），或SHOW PROCESSLIST（需PROCESS权限）；前者可排序过滤、字段完整，后者默认仅显示100行且INFO截断，推荐优先使用查询系统表方式。</p>

如何用 Navicat 查看 MySQL 的活跃会话（SHOW PROCESSLIST）

navicat 本身不提供独立的“会话管理器”界面，但能直接执行 sql 获取实时连接状态。核心方法是运行 show processlist 或更完整的 select * from information_schema.processlist —— 后者可排序、过滤、查到更多字段（比如 time、state、info）。

常见错误是只点“查询”新建窗口后直接敲 SHOW PROCESSLIST 却报错：Access denied; you need (at least one of) the PROCESS privilege(s) for this operation。这是因为当前登录用户缺少 PROCESS 权限，不是 Navicat 的问题，而是 MySQL 服务端限制。

确认权限：用高权限账号（如 root）连接，或让 DBA 执行 GRANT PROCESS ON *.* TO 'your_user'@'%'; FLUSH PRIVILEGES;
在 Navicat 查询窗口中粘贴并执行：SELECT ID, USER, HOST, DB, COMMAND, TIME, STATE, INFO FROM information_schema.PROCESSLIST ORDER BY TIME DESC;
INFO 字段可能为 NULL（比如正在执行的语句被隐藏），这时需搭配 SHOW FULL PROCESSLIST（需额外权限）或开启 general_log 临时抓取

PostgreSQL 用户该用什么命令替代 PROCESSLIST？

PostgreSQL 没有 PROCESSLIST，对应的是系统视图 pg_stat_activity。Navicat 连 PostgreSQL 时，同样靠手动查表获取会话信息。

执行以下语句即可看到所有活跃连接：

SELECT pid, usename, application_name, client_addr, backend_start, state, state_change, query FROM pg_stat_activity WHERE state = 'active' OR state = 'idle in transaction';

注意几个关键点：

pid 是 PostgreSQL 的进程 ID，可用于后续 pg_terminate_backend(<code>pid) 强制断开
state 值为 active 表示正在执行查询；idle in transaction 很危险——事务没提交却空闲，容易锁表
默认不显示完整 SQL（query 字段可能被截断），如需全量，需先设置 track_activity_query_size（需重启或 reload）

为什么 Navicat 的“连接”列表里看不到会话详情？

Navicat 左侧“连接”面板只显示你配置过的连接入口，不是实时数据库会话快照。它不轮询 information_schema.PROCESSLIST 或 pg_stat_activity，也不维护服务端连接状态映射。

也就是说：你删掉 Navicat 里的某个连接配置，不会 kill 任何正在运行的会话；反过来，你在服务器上 kill 了某个会话，Navicat 界面也不会自动刷新或报错——除非你主动执行查询时遇到连接中断。

误以为“断开连接”会终止服务端会话？其实只是关闭 Navicat 本地 socket，MySQL/PG 侧的线程仍可能残留（尤其未正确 commit/rollback 的事务）
想监控长期连接数增长？不能依赖 Navicat 界面，得写脚本定期查 information_schema.PROCESSLIST 并告警
Navicat Premium 16+ 的“服务器监控”功能仅支持 MySQL，且需开启 performance_schema，对 PG 无效

查到可疑会话后怎么安全终止？

别直接关 Navicat 窗口，先确认目标再操作。MySQL 和 PostgreSQL 终止方式完全不同，混用会报错。

MySQL 中终止指定会话（ID 为 123）：

KILL 123;

PostgreSQL 中终止（pid 为 456）：

SELECT pg_terminate_backend(456);

关键区别：

MySQL 的 KILL 命令不需要 SELECT，直接执行；PostgreSQL 必须用函数，且返回 true 才表示成功
MySQL 的 KILL QUERY 123 只中断当前语句，不杀连接；PostgreSQL 没对应语法，pg_terminate_backend 是彻底断连
如果会话正在执行 DDL（如 ALTER TABLE），强行终止可能导致元数据锁残留，尤其是 MySQL 5.7 之前版本

最常被忽略的一点：某些 ORM（如 Django、Laravel）会复用连接并保持长事务，看到一堆 sleep 状态不等于闲置，可能是等待应用层下一步指令——杀错了会影响业务逻辑。