navicat 不支持跨库分片建模，仅能对单库内分表进行物理设计与分区配置；分库逻辑需靠命名规范、分组文件夹和人工注释实现，跨库关联须手动标注且不可建立外键连线。
navicat 本身不支持直接建模“分库”逻辑，它能做的只是在单个数据库连接上下文中设计物理表结构、外键关系和分区策略；所谓“分库分表”的逻辑模型，必须靠人工抽象+命名规范+模块化组织来表达，否则工具会误判关联有效性。
Navicat 能建模的只有单库内分表，不是跨库分片
Navicat 的模型功能（仅 Premium 版）支持 MySQL、PostgreSQL 等主流数据库的逆向/正向工程，但它所有表关系都绑定在一个 connection 下。如果你把订单库、用户库、商品库分别连成三个独立连接，Navicat 不会自动识别它们之间的业务关联——更不会帮你画跨库外键线或生成分片路由逻辑。
实操建议：
- 把同一物理库内的分表（如
order_202607、order_202608）放进同一个模型里，用命名前缀/后缀明确区分时序或租户维度 - 跨库实体（如
users在 user_db，orders在 order_db）只能在模型中以“逻辑表”形式手动添加，并加注释说明其实际归属库名 - 避免在模型里强行拖拽跨库字段建立外键连线——Navicat 会报错或生成无效 DDL，且导出 SQL 时无法处理跨库引用
用命名规范和分组文件夹模拟分库结构
虽然 Navicat 模型不支持库级分组，但你可以用“模型分组”（Model Group）功能 + 表名约定，让逻辑更可读。例如电商系统中，把所有用户相关表归入 group_users，订单相关表归入 group_orders，并在每张表的备注（Comment）里写明：“物理库：user_db” 或 “分片键：tenant_id”。
常见做法：
- 表名统一加业务前缀：
user_profile、order_header、inventory_sku - 分表使用日期后缀：
log_event_202607，而非动态生成的log_event_yyyymmdd（Navicat 不解析变量） - 对需要水平拆分的大表，在模型中单独建一个“sharding template”表（如
order_template），只定义结构，不建真实表，用于后续批量生成分表 DDL
分区表可在 Navicat 中可视化配置，但要注意引擎限制
MySQL 的 RANGE、HASH 分区可以在 Navicat 设计表界面直接设置（右键表 → “设计表” → “分区”选项卡），但前提是存储引擎必须是 InnoDB 或 MyISAM（后者已弃用）。如果表用了 ARCHIVE 或 MEMORY，Navicat 会禁用分区配置入口。
容易踩的坑：
-
分区字段必须是主键或唯一索引的一部分，否则 Navicat 点击“保存”时会弹窗报错，错误信息类似：ERROR 1503 (HY000): A PRIMARY KEY must include all columns in the table's partitioning function - 用
DATE字段分区时，不能直接填created_at，得写成TO_DAYS(created_at)或YEAR(created_at)—— Navicat 的分区 UI 不自动包裹函数，需手动输入表达式 - 分区数不宜过多（建议 ≤ 64），否则 Navicat 加载表结构时会明显变慢，甚至卡死；超过 100 个分区的表，建议改用 DDL 脚本管理，别依赖图形界面
导出分表 DDL 时，务必手工替换表名和分区定义
Navicat 的正向工程导出 SQL，默认生成的是单表语句。如果你要批量创建 order_202607 到 order_202612 共 6 张分表，不能直接复制粘贴导出结果——因为每张表的 PARTITION 定义值不同（如 VALUES LESS THAN (7) vs VALUES LESS THAN (13)），且 CREATE TABLE 语句里的表名也得逐个改。
更可靠的做法：
- 在 Navicat 中建好一张基准分表（如
order_base），配置好字段、索引、分区逻辑 - 右键该表 → “复制为 SQL” → 得到完整 DDL
- 用文本编辑器批量替换：
order_base→order_202607，再手动调整PARTITION边界值 - 不要依赖 Navicat 的“批量生成”按钮——它只适用于同构表无分区场景
真正难的不是画出模型，而是决定哪些字段该冗余、哪些关联该降级为异步双写、哪些查询必须忍受跨库 JOIN。Navicat 只负责把你的决策具象化，它不会替你做分片键选型或一致性权衡。
