不准确——Navicat状态栏显示的耗时是客户端往返时间（RTT），含网络延迟、排队、锁等待等，不区分纯执行时间；真实执行耗时需查看结果集下方Info标签页中服务端返回的原始统计信息，如MySQL的“(0.042 sec)”、PostgreSQL的“Time: 0.037 ms”。
Navicat 状态栏显示的“耗时”到底准不准？
不准确——状态栏右下角显示的 query executed successfully (0.123s) 仅是客户端从发送请求到收到响应的**往返时间（rtt）**，包含网络延迟、服务端排队、锁等待、磁盘 i/o 等全部环节，但**不区分纯执行时间**。如果你在本地连本地 mysql，它接近真实耗时；但连远程 postgresql 或高负载 oracle 时，这个数字可能比实际 sql 执行时间大 5–10 倍。
真正能反映 SQL 执行耗时的位置：结果集下方的信息页
执行完查询后，别只看状态栏。切换到结果集面板下方的 Info 标签页（不是 History 或 Messages），这里会列出服务端返回的原始统计信息。不同数据库返回字段不同，但关键字段始终存在：
- MySQL / MariaDB：
Query OK, 1 row affected (0.042 sec)中的(0.042 sec)是服务端SELECT或INSERT的实际执行耗时（不含网络） - PostgreSQL：
Time: 0.037 ms（注意单位是毫秒，且精确到小数点后 3 位） - SQL Server：
SQL Server Execution Times: CPU time = 0 ms, elapsed time = 12 ms.，其中elapsed time更贴近真实执行耗时 - Oracle：
Elapsed: 00:00:00.089，即 89 毫秒，这个值来自服务端V$SQL视图的ELAPSED_TIME/1000000
为什么 Info 页的耗时有时为空或显示 “-”？
不是 Navicat 有问题，而是服务端没返回执行统计。常见原因：
- 执行的是多语句（如
SELECT * FROM t1; SELECT * FROM t2;），部分数据库驱动只返回最后一条的耗时 - 使用了事务控制语句（
BEGIN/COMMIT），这些语句本身不计入“查询耗时” - 连接配置中禁用了统计（如 PostgreSQL 的
client_min_messages设为warning以上） - Navicat 版本过旧（v15 以前对 SQL Server 和 Oracle 的耗时解析支持不全）
验证方法：在同个连接里执行一条简单 SELECT SLEEP(0.1)（MySQL）或 SELECT pg_sleep(0.1)（PostgreSQL），如果 Info 页仍无耗时，基本可判定是驱动或协议层未透出指标。
想长期追踪耗时？别依赖界面，改用服务端日志或性能视图
Navicat 的 Info 页只保留最近一次查询的耗时，关掉结果集就丢了。真要分析慢查询：
- MySQL：开启
slow_query_log，设置long_query_time = 0记录所有查询，再用mysqldumpslow分析 - PostgreSQL：在
postgresql.conf中设log_min_duration_statement = 0，日志里每条都有duration:字段 - 通用做法：在 SQL 开头加注释标记，例如
/* perf-test-20240520-A */ SELECT ...，再结合服务端pg_stat_statements或performance_schema.events_statements_summary_by_digest查历史平均耗时
界面看到的数字只是快照，服务端记录的才是真相——尤其当你要对比优化前后的执行时间时，Info 页的单次值根本不可靠。
