Navicat无法实时捕获“正在执行中”的SQL语句，因其非内核级监控工具，不挂钩线程栈或未返回结果集的查询上下文；所见“当前执行语句”实为数据库服务端通过PROCESSLIST或pg_stat_activity等视图暴露的定时快照，依赖权限（如MySQL需PROCESS、PG需SELECT pg_stat_activity）与配置，刷新延迟数百毫秒至数秒。
navicat 本身无法实时捕获“正在执行中（running）”的 sql 语句——它不是数据库内核级监控工具，不挂钩线程执行栈，也不读取未返回结果集的查询上下文。你能在 navicat 看到的“当前执行语句”，实际是数据库服务端已暴露给客户端的会话快照，依赖数据库自身的运行时视图和权限配置。
为什么在“服务器监控”里看不到实时 SQL？
很多人点开“工具→服务器监控”后只看到一堆连接数、CPU、内存图表，却找不到 SQL 列表——这是因为该面板默认不加载进程详情。必须手动选择一个已配置的 MySQL / PostgreSQL / SQL Server 实例（SQL Azure、MongoDB、Redis 不支持），且该连接账户需具备对应权限：
- MySQL：用户需有
PROCESS权限；否则Info列恒为NULL，Command可能只显示Sleep - PostgreSQL：需对
pg_stat_activity视图有SELECT权限；若连接参数含application_name且值敏感，某些版本会主动清空query字段 - SQL Server：需
VIEW SERVER STATE权限，否则进程列表为空或按钮置灰
如何正确打开并解读“进程列表”
进程列表不是右键菜单项，也不是查询窗口里的功能，路径唯一：工具 → 服务器监控 → 选中目标实例 → 点击“进程”标签页。加载成功后，重点关注以下字段：
-
ID：线程/后端 ID，终止操作时必需 -
User和Host：判断是否来自应用服务或定时任务 -
Command（MySQL）或State（PostgreSQL）：值为Query或active才代表真正在执行；Sleep/idle可忽略 -
Time：MySQL 是该线程持续运行秒数；PostgreSQL 是backend_start起始至今的秒数，需结合state_change判断是否卡住 -
Info：仅显示前 100 字符，长 SQL 必然被截断；双击单元格可展开完整语句（Navicat 16+ 支持）
Info 为空或显示 NULL 怎么办？
这不是 Navicat 的 Bug，而是数据库层限制。常见原因包括：
- MySQL 用户缺少
PROCESS权限，或show_compatibility_56关闭后旧协议行为异常 - PostgreSQL 中查询来自 PREPARE 语句、存储过程内部调用，或 JDBC 启用了
serverPrepStmts=true - SQL Server 中连接未启用
showplan权限，或查询走的是系统 SP 或加密对象 - 所有数据库类型下，若语句由其他客户端（如 Java 应用、Python 脚本）发起，Navicat 无法跨会话获取其原始 SQL
别急着重装或换工具——先用命令行验证权限：SHOW PROCESSLIST（MySQL）、SELECT * FROM pg_stat_activity（PostgreSQL）、SELECT * FROM sys.dm_exec_requests（SQL Server）。如果命令行也为空或无 sql_text，问题就在服务端配置或客户端连接方式上。
终止长 SQL 的实际限制
点击“结束进程”按钮前，务必确认权限边界：
- MySQL：普通账号只能杀自己发起的线程；要杀别人，需
SUPER或CONNECTION_ADMIN权限 - PostgreSQL：仅超级用户或该查询所属角色可调用
pg_terminate_backend()；且受pg_hba.conf认证策略限制 - SQL Server：需
ALTER ANY CONNECTION权限，否则按钮直接置灰 - 终止后列表不会自动刷新，需手动点刷新按钮，或等默认 30 秒周期
真正容易被忽略的一点：Navicat 的“进程列表”本质是定时轮询数据库视图的结果，它永远比真实线程状态慢几百毫秒到几秒——所以看到 Time=120 并不意味这句 SQL 已卡死两分钟，可能刚进入执行阶段不久，只是视图还没更新。排查高延迟问题时，不能只盯 Navicat 面板，得配合 performance_schema（MySQL）、pg_stat_statements（PostgreSQL）或扩展事件（SQL Server）做交叉验证。
