navicat 17 不支持快速创建分区表，其“可视化”仅是生成 partition by 语句的前端入口；分区配置入口唯一位于「设计表→选项」选项卡最底部灰色“分区”按钮，点击才弹出对话框，且不校验服务端兼容性、表达式合法性或锁风险，保存即执行高危 alter table。
navicat 17 不支持「快速创建分区表」——它没有独立的分区可视化管理界面，所谓“可视化创建”只是生成 create table ... partition by 或 alter table ... partition by 语句的前端入口，且极易因服务端限制或配置疏漏导致失败。
分区按钮在哪？为什么点不动？
在 Navicat 17 中，分区配置入口**只存在于「设计表」→「选项」选项卡最底部**，是一个灰色的「分区」按钮（不是复选框、不是下拉菜单），必须点击才弹出配置对话框。
常见不可用原因：
-
MySQL 8.0.29+默认禁用分区功能：需手动在my.cnf中添加loose-partition=ON并重启服务 - MySQL 实例未启用
partitioning插件：执行SHOW PLUGINS;确认partition行状态为ACTIVE - 连接的是 MySQL 5.7 但表使用了
InnoDB+ 非整型分区键（如DATE字段未包裹为TO_DAYS()） - 当前用户权限不足：至少需要
ALTER+CREATE权限
RANGE/LIST/HASH/KEY 分区类型怎么选？Navicat 不提示兼容性
Navicat 下拉菜单显示的分区类型，完全取决于你连接的 MySQL 版本和存储引擎，但它**不校验也不警告**是否合法。例如：
-
RANGE COLUMNS在 MySQL 5.5–5.6 中不支持，仅 5.7+ 支持；但 Navicat 17 仍会允许你选择并保存，执行时直接报错：ERROR 1064 (42000): This partition function is not allowed -
HASH和KEY要求分区键必须是索引前缀字段；若你选了created_at但该字段没出现在任何索引最左侧，保存后 DDL 执行会失败 -
LIST分区值必须是显式枚举的常量（如VALUES IN (1,2,3)），不能写表达式；Navicat 不阻止你输错，错误留到执行时暴露
保存即执行 ALTER TABLE，大表千万别直接点确定
Navicat 对已有表点「保存」分区配置，等价于提交一条完整 ALTER TABLE t_name PARTITION BY ... 语句——这不是元数据变更，而是物理操作：
- MySQL 5.7：触发全表重建，锁表时间与数据量正相关，期间写入阻塞
- MySQL 8.0：虽优化为原子 DDL，但仍需升级元数据锁（
MDL_EXCLUSIVE），并发写入会被挂起 - 若分区定义有误（如
RANGE第一个分区上限设为100，但表里已有id=150的数据），执行中断后表可能进入「可读不可写」状态，且无法自动回滚
务必先导出原表结构，用 mysqldump --no-data 拿到建表语句，在测试库中手工补上 PARTITION BY 再执行验证。
分区表达式写什么？NOW()、UUID() 这类函数会静默失败
Navicat 不校验分区表达式的确定性（deterministic），只负责拼接 SQL。以下写法看似合理，实则必报错：
-
NOW()→ 报错：ERROR 1486 (HY000): Constant, random or timezone-dependent expressions... -
CONNECTION_ID()、USER()、RAND()同理 - 正确写法必须是确定性函数，且字段需为索引前缀：如
TO_DAYS(created_at)、YEAR(created_at)、id（前提是id是主键或联合索引最左列）
特别注意：RANGE COLUMNS (created_at) 要求 created_at 字段本身出现在某索引最左侧，否则建表会失败，Navicat 不提示。
实际操作中，最易被忽略的是：Navicat 从不告诉你「这个分区按钮点下去之后，背后执行的是高危 DDL」。它把复杂度藏在了图形界面之下，而错误只在执行那一刻炸开。别信「可视化=安全」，每一步都要对照 MySQL 官方文档确认版本兼容性、表达式合法性、锁行为影响。
