Navicat for MariaDB 不支持可视化设计 CHECK 约束，无论版本新旧，表设计器、对象设计器及查询创建工具均无图形化配置入口；其 UI 仍基于 MySQL 5.7 元数据模型，未适配 MariaDB 10.2.1+ 的 CHECK 支持。
Navicat for MariaDB 不支持可视化设计 CHECK 约束。这是关键事实，不是操作门槛问题，而是功能缺失——无论版本新旧（包括最新版 Navicat 17），其表设计器、对象设计器或查询创建工具中均无 CHECK 约束的图形化配置入口。
为什么表设计器里找不到 CHECK 选项
MariaDB 自 10.2.1 起才正式支持 CHECK 约束（此前仅解析语法但不执行校验），而 Navicat 的 UI 层并未同步适配该特性。它的表设计器仍沿用面向 MySQL 5.7 时代的元数据模型，只暴露 NOT NULL、UNIQUE、PRIMARY KEY 和外键等传统约束字段，对 CHECK 完全忽略。
- 你右键表 → “设计表”，在“约束”或“索引”标签页里搜不到
CHECK相关控件 - 即使手动在“SQL”标签页写入
ADD CONSTRAINT chk_age CHECK (age >= 0)，保存后也不会被 UI 反向识别或显示 - Navicat 的“结构同步”工具在比对时也会跳过
CHECK约束，导致跨环境迁移时静默丢失
绕过限制：用 SQL 编辑器直接定义
必须切换到纯 SQL 模式才能可靠添加或修改 CHECK 约束。Navicat 的查询编辑器支持语法高亮和执行计划，是唯一可行路径：
- 打开新查询窗口，连接目标数据库
- 执行
ALTER TABLE users ADD CONSTRAINT chk_status CHECK (status IN ('active', 'inactive')); - 若需修改已有约束，MariaDB 不支持
ALTER ... DROP CHECK（直到 10.12+ 才加入），只能先ALTER TABLE ... DROP CONSTRAINT old_name再重建 - 注意：约束名在 MariaDB 中是可选的，但强烈建议显式命名（如
chk_status），否则报错时无法精准定位
容易被忽略的兼容性坑
即便 SQL 执行成功，CHECK 约束的行为也受 MariaDB 版本和 SQL 模式双重制约：
- 低于 10.2.1 的 MariaDB 会静默忽略
CHECK子句（不报错也不生效） - 若会话启用了
IGNORE_BAD_TABLE_OPTIONS，即使语法错误也不会中断执行 -
STRICT_TRANS_TABLES模式下插入违规数据会报错；非严格模式下可能转为警告并插入默认值，使约束形同虚设 - Navicat 的“数据同步”或“数据生成”工具完全不感知 CHECK 约束，生成测试数据时可能批量违反规则
真正要靠 CHECK 约束兜底，就得接受它是个“手写即生效、UI 不可见、同步不携带”的裸 SQL 特性——别指望可视化界面帮你验证逻辑或防止误删。
