navicat不支持自动分库分表，仅提供多独立模型模拟分片库结构；需为每个分片库单独新建模型并导入对应表，禁用跨模型同步，用layer视觉分组，导出sql时须手动补全分区语法、删除外键、添加drop语句。
navicat 本身不支持自动分库分表，也没有内置的分片路由或跨库查询能力；它只提供模型层面的结构表达和可视化辅助。所谓“分库分表前的模型演练”，本质是用多个物理模型分别模拟不同分片库的表结构，并手动维护它们之间的逻辑一致性——这需要你主动设计、严格命名、避免重叠，否则模型就只是几张好看但不可落地的图。
如何创建多个独立模型对应不同分片库
不能在一个模型里混放所有分片表（比如 user_shard_01 和 user_shard_02 放在同一模型中），否则正向工程导出 SQL 时会冲突、同步到数据库时无法指定目标连接。正确做法是为每个分片库单独建一个模型：
- 点击主工具栏“模型” → “新建模型”，选择对应数据库类型（如
MySQL 8.0） - 在新模型中，通过“文件”→“从数据库导入”→ 仅选中该分片库（如
shop_db_01）下的表 - 重复上述步骤，为
shop_db_02、shop_db_03各建一个模型，文件名建议带分片标识，如shop_db_01.ndm2 - 所有模型保存后，右键任一模型 → “打开所在的文件夹”，可集中管理这些
.ndm2文件
为什么不能依赖 Navicat 的“逆向工程”直接生成分片模型
Navicat 的逆向工程（如“逆向模式到模型”）只会把当前连接下看到的整个 schema 拉成一张图，它不识别分片语义，也不会帮你拆解 user 表在不同库中的变体。常见错误包括：
- 误将所有分片库连到同一个 Navicat 连接下，再逆向整个“数据库列表”，结果模型里出现大量同名表（
user出现 4 次），字段冲突、关系错乱 - 试图在单个模型内用“虚拟外键”连跨库表（如
shop_db_01.order→shop_db_02.user），但这类连线无法导出有效 SQL，也不能被任何数据库执行 - 未关闭“自动同步命名”选项，导致修改一个模型里的
order_id类型，其他模型也跟着变——实际各分片库字段类型可能因历史原因不一致
用层（Layer）和颜色标记区分分片维度与业务域
当多个模型都打开时，单靠文件名易混淆。可在每个模型内部用 Layer（层）功能做轻量级语义分组，比纯靠窗口标签更可靠：
- 在模型设计器右侧工具栏点击
Layer→ “新建层”，命名为shard-01、tenant-a或hot_data - 把属于该分片/租户/冷热类型的表拖进对应层，右键层可设背景色（如
shard-01设为浅蓝，shard-02设为浅绿） - 禁用“层可见性联动”：默认勾选“显示/隐藏所有层”，要取消勾选，否则切换层会意外隐藏其他模型里的表
- 注意：Layer 不影响导出 SQL，只是视觉组织手段；不要把它当成权限或部署单元
导出分片 SQL 时最容易漏掉的三件事
从模型导出 SQL 是演练落地的关键一步，但 Navicat 默认行为会掩盖真实分片约束：
- 导出时不勾选“包含 DROP TABLE”，会导致脚本在已有库上执行失败（因为
CREATE TABLE user冲突）；必须手动加DROP TABLE IF EXISTS user;或改用REPLACE INTO逻辑 - 模型里没显式定义的分区规则（如
PARTITION BY HASH(id)）不会出现在导出 SQL 中——Navicat 的模型不支持 MySQL 分区语法建模，需人工补全 - 外键约束在分片场景下基本失效，但模型仍可能保留虚拟外键连线；导出前务必检查 SQL 中是否含
FOREIGN KEY子句，有则删掉，否则在目标库执行报错
真正难的不是画出分片模型，而是保证每个模型里的表名、字段名、索引策略、注释都严格遵循分片规范——比如所有 shard_01 库的 user 表必须带 shard_id TINYINT NOT NULL DEFAULT 1 字段，且该字段必须出现在所有联合查询的 WHERE 条件里。这些规则 Navicat 不校验，只能靠你写 checklist 手动核对。
