navicat 17 无内置 profiling 功能，因其仅为客户端工具，不采集 cpu/io 等底层指标；它仅封装并可视化数据库原生分析命令（如 explain analyze、pg_stat_statements），需手动配置数据库端启用对应功能。
navicat 17 本身不提供 profiling 功能，也不能直接监控 cpu 开销；它依赖后端数据库自身的性能分析能力，比如 mysql 的 set profiling = 1 或 postgresql 的 \timing 和 pg_stat_statements。
为什么 Navicat 17 界面里找不到 Profiling 开关
Navicat 是客户端工具，不是数据库服务进程。它没有权限、也不负责采集 CPU、IO 或内存级别的运行时指标。所谓“性能剖析器”在 Navicat 17 中实际指代的是对数据库原生性能数据的可视化呈现与辅助调用，而非独立实现的 profiler。
常见误解是看到“SQL 性能分析器”菜单就以为能像 IDE 那样做函数级耗时统计——其实它只是封装了 EXPLAIN ANALYZE（PostgreSQL）、EXPLAIN FORMAT=JSON（MySQL）等命令，并把执行计划转成图形化流程图。
- 真正采集 CPU 时间的是数据库服务自身（如 MySQL 的
performance_schema或 PostgreSQL 的pg_stat_statements） - Navicat 只能发起查询、展示结果、点击跳转查看执行计划
- 若数据库未启用对应扩展（例如 PostgreSQL 没开
pg_stat_statements），Navicat 就查不到任何历史耗时数据
如何在 Navicat 17 中间接使用 Profiling 类功能（以 MySQL 为例）
你需要手动配合数据库配置 + Navicat 的 SQL 执行窗口完成三步闭环：
- 先在 Navicat 连接中执行
SET profiling = 1;（注意：该功能在 MySQL 8.0+ 已被弃用，仅适用于 5.7 及更早版本） - 运行你要测的语句，比如
SELECT * FROM orders WHERE created_at > '2025-01-01'; - 再执行
SHOW PROFILES;，Navicat 会显示每条语句的Duration字段值 - 想看详细阶段耗时？执行
SHOW PROFILE FOR QUERY N;（N 是上一步中的 Query_ID）
⚠️ 注意：profiling 是会话级开关，断开连接即失效；且它不记录 CPU 占用率，只记录各阶段 wall-clock 时间（含等待 IO、锁等）。
替代方案：用 Navicat 17 调用 pg_stat_statements（PostgreSQL）
这是目前更可靠、生产环境推荐的方式。前提是数据库已启用该扩展：
- 确认是否启用：
SELECT * FROM pg_extension WHERE extname = 'pg_stat_statements'; - 若无结果，需由 DBA 在
postgresql.conf中添加shared_preload_libraries = 'pg_stat_statements'并重启 - 在 Navicat 中执行查询：
SELECT query, total_time, calls, mean_time FROM pg_stat_statements ORDER BY total_time DESC LIMIT 10; - Navicat 会直接列出最耗时的 TOP 10 查询及其平均/总耗时（单位毫秒）
这个结果比 profiling 更稳定、可跨会话聚合，也更接近真实负载下的性能画像。
容易被忽略的关键点
很多人以为打开 Navicat 的“服务器监控面板”就能看到某条 SQL 的 CPU 占用——其实那只是操作系统级的汇总指标（如整个 mysqld 进程的 CPU%），和具体哪条语句无关。
真正定位单条 SQL 的资源消耗，必须依赖数据库内建的统计视图或执行计划；而 Navicat 的价值在于把 EXPLAIN 结果画成树状图、把 pg_stat_statements 表格自动排序、把慢查询日志高亮标记——它不生成数据，只让已有数据更易读、更易钻取。
