navicat中查看mysql活跃会话需执行select * from information_schema.processlist（无需process权限），或show processlist（需process权限）；前者可排序过滤、字段完整，后者默认仅显示100行且info截断，推荐优先使用查询系统表方式。
如何用 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 状态不等于闲置，可能是等待应用层下一步指令——杀错了会影响业务逻辑。
