Navicat 图表可视化不采集性能指标，但可将结构化性能数据源（如定时采集的 db_perf_summary 表）快速转化为交互图表；需用 capture_time 作时间轴、database_name 作图例、添加阈值线，并启用交叉筛选；通过计算字段支持业务指标（如 login_failure_rate），语法适配数据库类型；数据源须设为链接模式，注明更新频率与权限管控。
navicat 的图表可视化功能本身不直接采集或计算数据库性能指标（如 cpu 使用率、锁等待时间、查询延迟），但它能快速把已有性能数据“画出来”，让团队一眼看出瓶颈在哪、变化趋势如何、不同环境间差异多大——前提是你要先有结构化的性能数据源。
把性能日志或监控表变成可交互图表
Navicat BI 不会自动抓取 SQL Server 的 sys.dm_exec_query_stats 或 MySQL 的 performance_schema，但你可以手动建一张汇总表（比如每天定时跑一次采集脚本写入 db_perf_summary），然后把它作为数据源接入 Navicat BI。常见字段包括：capture_time、avg_duration_ms、exec_count、database_name、query_hash 等。
关键操作建议：
- 用
capture_time作为 X 轴时间维度，选折线图或面积图，开启「平滑曲线」更易识别拐点 - 把
database_name或host_name设为图例字段，方便横向对比多个实例 - 对
avg_duration_ms添加上四分位线（Q3）或自定义阈值线（比如 500ms），超过即标红突出 - 右键图表 → 「启用交叉筛选」，点击某时段后，所有同源图表（如慢查数量、连接数、错误率）同步高亮响应
用自定义字段快速生成业务口径性能指标
原始性能数据往往只含技术字段，但团队真正关心的是“订单支付超时率”“用户登录失败占比”这类业务语义指标。Navicat BI 的「计算字段」能直接在界面里写表达式，不用改底层表。
例如，从 app_logs 表中已有 status_code 和 endpoint 字段，想统计“/api/v1/login” 接口的失败率：
IF([status_code] != 200 AND [endpoint] = '/api/v1/login', 1, 0) / COUNT(*) OVER (PARTITION BY [endpoint])
注意点：
- 表达式语法取决于你连的数据库类型（MySQL 用
IF，PostgreSQL 用CASE WHEN），Navicat 会实时校验语法有效性 - 避免在计算字段里写复杂子查询，容易拖慢图表加载；聚合类指标优先在数据库层预计算好再导入
- 命名别用空格或中文，比如叫
login_failure_rate，否则后续做趋势线或联动筛选可能出错
多人协作时图表权限和更新逻辑必须明确
图表一旦共享到 Navicat 协同工作区，所有人看到的是同一份定义，但背后数据是否实时？谁有权修改？这些不厘清，很快就会出现“张三看的是昨天的数据，李四刚改了筛选条件却没通知大家”这类混乱。
实操底线：
- 所有性能图表的数据源必须设为「链接模式」而非「导入模式」，确保刷新即读最新库表
- 在仪表板顶部加一个文本框，写明数据更新频率（如“每小时 00 分自动刷新”）和最后成功时间（可用
NOW()函数动态显示） - 禁用非 DBA 成员对核心性能数据源的编辑权限，只开放「查看+导出」；自定义字段和图表样式可由分析人员自行调整
- 避免在同一个仪表板里混用不同时间粒度的数据（比如把秒级慢查日志和小时级资源监控画在同一张图上），轴缩放会失真
最常被忽略的一点：图表再漂亮，如果没人定期看、没人对照它去验证优化动作是否生效，它就只是个装饰。建议把关键性能图表嵌入每日站会的共享屏幕，用「过去 24 小时最大值 vs 上周均值」这种一句话结论替代全部坐标轴。
