报错1064的主因是默认值栏误加引号、括号或DATETIME类型不兼容：正确应输入CURRENT_TIMESTAMP（无引号无括号），且优先使用TIMESTAMP类型。
Navicat设 CURRENT_TIMESTAMP 报错 1064？大概率是引号或字段类型不兼容
直接说结论：navicat 里给 create_time 字段设默认值为 current_timestamp 却报 1064，90% 是因为你在“默认值/表达式”栏里加了引号、括号，或者误用了 datetime 类型（尤其在 mysql 5.6 及更早版本中）。
MySQL 对 CURRENT_TIMESTAMP 的语法非常敏感——它必须是裸写、无引号、无括号的字面量表达式，且只对 TIMESTAMP 原生支持默认值；DATETIME 在 MySQL 5.6.5+ 才支持，但 Navicat 旧版 UI 可能仍按老规则生成 SQL。
- ✅ 正确输入：
CURRENT_TIMESTAMP（全大写/小写均可，但别加任何符号） - ❌ 错误输入：
'CURRENT_TIMESTAMP'、CURRENT_TIMESTAMP()、"CURRENT_TIMESTAMP" - ⚠️ 注意：若你用的是
DATETIME类型，且 MySQL 版本 TIMESTAMP 或改用触发器
为什么“新建表时就填默认值”容易失败？Navicat 自动生成 SQL 的坑
Navicat 在“新建表”界面首次定义字段时，如果当场在“默认值/表达式”里填了 CURRENT_TIMESTAMP，它可能生成非法建表语句，比如把 DEFAULT CURRENT_TIMESTAMP 错写成 DEFAULT 'CURRENT_TIMESTAMP'，直接触发 1064。
这不是你手误，而是 Navicat 某些版本（尤其是 15.x 之前）的 UI 逻辑缺陷：它把“表达式”和“字符串常量”混为一谈，没做类型区分。
- ✅ 推荐做法：先建表（所有字段默认值留空），保存成功后再右键 → 设计表 → 单独编辑
create_time行，只改“默认值/表达式”为CURRENT_TIMESTAMP，再点保存 - ✅ 验证是否成功：右键表 → 对象信息 → DDL 标签页，确认看到的是
`create_time` datetime DEFAULT CURRENT_TIMESTAMP，而不是带引号的版本 - ⚠️ 如果 DDL 里出现
DEFAULT 'CURRENT_TIMESTAMP'，说明 Navicat 已经“固化”了错误逻辑，此时建议手动执行ALTER TABLE修正
报错 1067 “Invalid default value for ‘xxx’”？严格模式在拦你
这个错误和时间字段默认值有关，但根源不在 Navicat，而在 MySQL 的 SQL 模式。MySQL 5.7+ 默认启用严格模式，其中 NO_ZERO_DATE 和 NO_ZERO_IN_DATE 会拒绝 '0000-00-00' 或 '0000-00-00 00:00:00' 这类零值，默认值一旦被 Navicat 错误生成为这种格式，就会炸。
- ✅ 快速验证：执行
SELECT @@sql_mode;，看输出里是否含NO_ZERO_DATE或NO_ZERO_IN_DATE - ✅ 临时绕过（仅开发环境）：
SET SESSION sql_mode = (SELECT REPLACE(@@sql_mode, 'NO_ZERO_IN_DATE,NO_ZERO_DATE', '')); - ⚠️ 注意：不要全局关闭这些模式用于生产环境；真正解法是确保建表语句里没有零日期，默认值只用
CURRENT_TIMESTAMP或合法时间字符串如'2026-01-01 00:00:00'
锁表排查？其实多数时候根本没锁，是 Navicat 自己卡在元数据校验
有人遇到“设置默认值后 Navicat 卡住、光标转圈、疑似锁表”，其实不是 MySQL 锁了表，而是 Navicat 在后台反复尝试解析它自己生成的非法 DDL，陷入校验失败循环。你查 SHOW PROCESSLIST 会发现根本没有长时间运行的 ALTER 或 UPDATE。
- ✅ 立即响应：关掉当前设计表窗口，重新右键 → 设计表，只动“默认值/表达式”那一格，其他不动
- ✅ 终极保险：放弃图形界面，直接执行 SQL：
ALTER TABLE `your_table` MODIFY `create_time` TIMESTAMP DEFAULT CURRENT_TIMESTAMP; - ⚠️ 提醒：Navicat 的“设计表”本质是 UI 封装，它对时间类型、表达式、版本兼容性的判断远不如手写 SQL 精准——越关键的字段，默认值越建议绕过 UI 直接写
