Navicat BI 是深度集成于 Navicat Premium 17 和 Enterprise 17 的分析功能，非独立模块；跨平台操作逻辑、字段映射及仪表板行为完全一致，但需对应许可证支持，且 PostgreSQL 字段名大小写敏感，SQL 中建议用双引号规范别名。
Navicat BI 在 Navicat 17 中不是独立模块，而是深度集成的分析能力——它不依赖本地运行环境差异，只要 Navicat 17 安装完成（Windows/macOS/Linux 均支持），BI 功能就可用。关键不在“跨平台创建”，而在于**数据源连接方式**和**图表渲染逻辑是否随平台变化**：实际不影响，所有操作逻辑、字段映射、计算字段语法、仪表板布局行为完全一致。
确认 Navicat 17 是否启用了 BI 功能
不是所有 navicat 17 版本默认带 bi：navicat premium 17 和 navicat enterprise 17 支持；navicat standard 或旧版升级包不包含。启动后若顶部菜单栏没有 bi 按钮，说明当前许可证不支持该功能。
常见误判点：
- 已安装 Navicat 17，但未激活企业/高级许可 →
BI按钮不出现 - 在 macOS 上用 Rosetta 运行 x86 版本 → BI 功能正常，但部分 ODBC 驱动可能加载失败（非 BI 本身问题）
- Linux 版缺少 GTK 依赖（如
libgtk-3-0）→ 启动失败或界面错位，需手动补全系统库
连接 PostgreSQL dvdrental 数据源时字段名大小写敏感
dvdrental 是 PostgreSQL 示例库，其表名、列名默认小写，但 Navicat BI 在解析 SQL 查询结果时，会保留原始大小写。如果你在查询中写了 SELECT c.NAME（大写），BI 字段列表里就会显示 NAME；而拖拽进饼图的 group 槽时，若误选了 name（小写）字段，图表将报错 "Field not found" 或空白渲染。
实操建议：
- 统一在 SQL 查询中使用双引号包裹别名，例如
SELECT c.name AS "category_name"，确保字段名稳定可识别 - 导入查询前，在 Navicat 查询编辑器中执行
EXPLAIN或直接查看结果集列头，确认最终输出字段名 - 避免在字段名中混用空格、连字符或中文——BI 内部解析器对这类字符支持不稳定，尤其在 Linux 终端环境下易触发编码异常
饼图中 sum(amount) 显示百分比但数值不匹配预期
你拖入 sum 聚合到饼图 value 槽，默认显示的是「占总和的百分比」，但底层计算依赖两个隐式条件：是否启用「自动汇总」、是否过滤了 NULL 分组。
典型偏差场景：
- SQL 查询中
LEFT JOIN导致部分c.name为NULL→ 这些记录被计入分母但不显示在饼图中，造成百分比总和 - BI 工作区缓存了旧查询结果，而数据库中
payment表已新增数据 → 图表未刷新，显示过期比例 - 在「属性」面板勾选了
Show values as percentage，但未关闭Display absolute values→ 数值重叠、字体挤压，误以为计算错误
验证方法：右键图表 → View Data，检查弹出表格中各 name 对应的 sum(amount) 是否与数据库原始聚合一致。
仪表板发布后同事打不开或图表空白
Navicat BI 的仪表板文件（.ndb）本质是加密打包包，内含数据源连接信息快照 + 图表定义 + 自定义字段逻辑，但不含真实数据行。因此共享时必须满足：
- 接收方也安装了相同版本的
Navicat 17（如你用 17.3.12，对方不能是 17.2.8） - 对方拥有访问同一数据库的权限，且连接名、用户名、密码（或已保存的连接配置）与你创建时一致；否则加载时卡在「Connecting...」
- 若你使用了自定义计算字段（如
DATEADD()或AGGCOUNT()），对方机器上函数支持度需一致 —— 尤其注意 macOS/Linux 下某些日期函数返回格式略有差异
最稳妥的共享方式不是发 .ndb 文件，而是导出为 PNG 或 PDF（仅静态视图），或通过 Navicat Cloud 同步整个工作区（需双方登录同一账号）。
dvdrental 查询在你的本地连接中耗时 800ms，那么在仪表板中点击某个扇形筛选时，延迟会更明显——这不是跨平台问题，而是 SQL 优化盲区。先确保查询本身带索引（比如在 film_category.film_id 和 category.category_id 上），再谈可视化流畅度。
