navicat模型设计器不支持直接创建分表结构，仅能作为单表建模与ddl模板工具，分表需人工批量生成物理表并由应用层或中间件实现路由与管理。
Navicat 模型设计器不支持直接创建分表结构
Navicat for MySQL 的模型设计器（Model Designer）本质是 ER 图建模工具，它生成的是单张逻辑表的 CREATE TABLE 语句，**不会、也不能自动生成分表逻辑（如按月分表、按 ID 取模分表）或分表路由规则**。所谓“分表”，在 MySQL 层面没有原生语法支持，它依赖应用层控制或中间件（如 MyCat、ShardingSphere）或手动建多个物理表 + SQL 路由。模型设计器连 CREATE TABLE ... PARTITION BY（MySQL 原生分区）都仅作有限可视化，更别说业务意义上的分表。
能用模型设计器做的实际操作只有这三步
如果你仍想借助模型设计器辅助分表设计，只能把它当“画图+建单表模板”工具，后续必须人工补全：
- 在模型中新建一张表（例如
order_base），定义好字段、主键、索引、注释等通用结构 - 导出该表的 DDL（右键表 →
Quick DDL），保存为模板 SQL - 用脚本批量生成分表语句：比如复制模板，把表名替换成
order_202401、order_202402等；注意手动调整PARTITION定义（如果走原生分区）或确保各分表结构完全一致
Navicat 不提供“批量生成同构表”功能，也不解析或校验分表间约束关系——比如你无法在模型里声明“order_202401 和 order_202402 共享同一套外键逻辑”，因为 MySQL 外键不跨表生效，模型设计器也无此建模能力。
常见错误：误把分区表当分表，还指望模型自动同步
有人在模型里勾选了 PARTITION BY RANGE 并填了 TO_DAYS(created_at)，以为保存后 Navicat 会自动建出多个分区文件或子表——不会。模型设计器只负责生成带 PARTITION 子句的单条 CREATE TABLE 语句，是否真正分区、分区是否生效、数据是否落入正确分区，全看执行时 MySQL 版本是否支持、语法是否写对、以及后续 ALTER TABLE ... REORGANIZE PARTITION 等运维操作。而且 Navicat 模型不跟踪分区状态，改了分区策略必须重新导出 DDL 再执行，不能“一键同步”。
更关键的是：MySQL 分区 ≠ 分表。分区是单表内部物理切分，仍是一个逻辑表名、一套索引、事务可见性统一；而业务分表（sharding）是多张独立表，需应用自己拼 SQL、处理跨分表 JOIN 或聚合——模型设计器对后者完全无感。
真正要落地分表，绕不开这三件事
模型设计器在这里几乎不参与核心流程：
- 选型决策：确认是用应用层分表（如 ShardingSphere-JDBC）、代理层（ShardingSphere-Proxy）、还是纯手工管理。Navicat 对这三者均无集成支持
-
SQL 适配：分表后
SELECT * FROM order必须变成SELECT * FROM order_202403，WHERE 条件里的分片键（如user_id % 4）必须由代码计算，模型设计器不生成也不验证这类逻辑 - 元数据维护：新增一个分表，你要手动在 Navicat 中连上对应库、执行建表语句、可能还要刷新连接才能看到——模型文件和数据库实际结构从此脱钩，靠人对齐
模型设计器唯一省力的地方，是帮你避免手写重复的字段定义。但只要涉及分表，这个“省力”就只占整个实施成本的不到 5%。真正卡点永远在路由规则设计、分布式 ID、跨分表事务、以及数据迁移时的双写一致性——这些 Navicat 根本不碰。
