Navicat虚拟组是纯客户端UI分组机制，依赖连接名严格匹配与Schema可见性设置；需通过连接层、分组层、配置同步联动管理多实例，配置存于vgroup.json并须纳入Git校验。
Navicat 的虚拟组（vgroup）不是“分库分表的逻辑分组”，而是纯客户端侧的 UI 组织机制——它不改变数据库结构，也不影响 SQL 执行，只在 Navicat 界面里折叠/筛选/隔离表。跨平台开发中真正能靠它统一管理数百个实例的关键，在于「连接层 + 分组层 + 配置同步」三者联动，而不是单靠拖拽建组。
虚拟组依赖连接名严格匹配 conn_name
虚拟组配置存于 profiles/vgroup.json，其中每个分组必须绑定一个明确的连接名：conn_name 字段值需与 Navicat 中该连接的「连接名称」完全一致（区分大小写、空格）。常见错误是：导出配置后手动改了连接名但没同步更新 vgroup.json 里的 conn_name，结果分组在本地不显示。
- Windows 上连接名为
prod-mysql-01，Mac 上同个连接若被重命名为PROD_MYSQL_01，原分组将失效 - 团队共用配置时，建议在连接创建阶段就约定命名规范，例如：
[env]-[dbtype]-[region]→staging-postgres-usw2 - 可通过 Navicat「连接属性 → 常规」页反复确认当前连接名，别信左侧面板显示的别名
跨 Schema / 跨 Catalog 分组需显式启用“显示所有”
Navicat 默认只加载当前默认 Schema（如 MySQL 的 database，PostgreSQL 的 public schema），未勾选「显示所有 Schema」时，即使你在 vgroup.json 里写了跨 Schema 的表，也不会出现在组内。这不是 bug，是设计行为。
- 操作路径：右键连接 → 「连接属性」→ 「高级」选项卡 → 勾选「显示所有 Schema」（MySQL）或「显示所有 Catalogs/Schemas」（PostgreSQL/SQL Server）
- 勾选后，左侧对象树会展开全部 Schema，此时拖拽
sales.orders和log.audit_log到同一虚拟组才真正生效 - 注意 PostgreSQL 的 catalog（database）级隔离更严格，若两个表在不同 database，Navicat 无法跨库建组——虚拟组只支持同连接内、同 catalog 下的 schema 表聚合
批量生成分组配置：用正则 + jq 替代人工拖拽
面对上百张表，逐个拖进组效率极低，且不可复现。Navicat 16+ 支持正则匹配表名自动归类，但仅限 GUI 操作；要批量生成可版本控制的 vgroup.json，得绕过界面直接构造 JSON。
- 先用 SQL 提取目标表清单（以 MySQL 为例）：
SELECT table_schema, table_name FROM information_schema.tables WHERE table_name REGEXP '^oms_|^pay_' AND table_schema = 'prod_db';
- 用脚本（Python 或 jq）按前缀聚合成多个
vgroup_items数组，例如：{"vgroup_name": "order_v2", "vgroup_type": "TABLE", "items": [...]} - 合并进
vgroup.json时，务必用jq按层级追加，不能简单拼接 JSON 数组（会破坏连接层嵌套结构）：jq '.connections[] |= if .conn_name == "prod-mysql-01" then .catalogs[].schemas[].vgroups += $new | .catalogs[].schemas[].vgroups |= unique else . end' vgroup.json --argjson new '[{"vgroup_name":"order_v2","items":[...]}]'
虚拟组真正的复杂点不在创建，而在「连接名漂移」和「Schema 可见性隐式关闭」——这两个问题不会报错，只会让分组静默失效。建议把 vgroup.json 纳入 Git 仓库，并在 CI 流程中用 jq 校验每个 vgroup 的 conn_name 是否存在于当前连接列表，避免团队协作时配置失联。
