Navicat查看当前活跃数据库连接会话详情的方法

Na vicat中查看MySQL活跃会话的正确姿势

先阐明一个核心观点：在Na vicat中查看MySQL活跃会话，最直接的方式就是查询系统表information_schema.PROCESSLIST。这个操作不需要PROCESS权限，而且可以排序、过滤，字段也更完整。相比之下，SHOW PROCESSLIST虽然也能用，但默认只显示100行，INFO字段还会被截断。所以，代码习惯上，优先推荐使用查询系统表的方式。

坦白说，Na vicat本身并没有一个独立的“会话管理器”界面，但别担心，直接通过SQL查询就能实时获取连接状态。核心方法有两个：运行SHOW PROCESSLIST，或者更完整的SELECT * FROM information_schema.PROCESSLIST。后者能查到更多字段，比如TIME、STATE、INFO，并且可以按需排序和过滤。

常见的一个错误是：在Na vicat的查询窗口里直接敲SHOW PROCESSLIST，却报错Access denied; you need (at least one of) the PROCESS privilege(s) for this operation。问题的根源不在Na vicat，而是MySQL服务端限制——当前登录用户缺少PROCESS权限。

解决办法：

• 确认权限：用高权限账号（比如root）连接，或者让DBA执行GRANT PROCESS ON *.* TO 'your_user'@'%'; FLUSH PRIVILEGES;
• 在Na vicat查询窗口中粘贴并执行：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。Na vicat连接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(pid)来强制断开连接。
• state值为active表示正在执行查询；idle in transaction很危险——事务没提交却空闲，容易锁表。
• 默认不显示完整SQL（query字段可能被截断），如果非要看全量，需要先设置track_activity_query_size（需重启或reload）。

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

这其实是一个很常见的误解，但需要澄清：Na vicat左侧的“连接”面板，只显示你配置过的连接入口，并不是实时数据库会话快照。它不会主动轮询information_schema.PROCESSLIST或pg_stat_activity，也不维护服务端连接状态映射。

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

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

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

掌握了查看方法，下一个问题自然就是：看到可疑会话后，怎么安全地终止它？别直接关Na vicat窗口，先确认目标再操作。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、Lara vel）会复用连接并保持长事务。看到一堆sleep状态，不等于闲置，可能是等待应用层下一步指令——杀错了会影响业务逻辑。