Navicat 15 新建表报 ERROR 1064 主因是其缓存的 MySQL 版本与实际版本（如显示 8.0.33 但实为 5.7.42）不符，导致生成不兼容语法；须执行 SELECT VERSION() 和 SELECT @@version_comment 确认真实版本，并手动修改 SQL 中 utf8mb4_0900_ai_ci、ALGORITHM=INSTANT 等高版本语法，再通过「文件→运行 SQL 文件」以 UTF-8（无 BOM）方式执行。
Navicat 15 新建表保存时报 ERROR 1064，基本不是你手输错了字段名或类型，而是它自动生成的建表语句里混入了目标 MySQL 版本不认的语法——尤其当 Navicat 连接显示版本（比如 8.0.33）和你真实数据库版本（比如 5.7.42）不一致时，问题必现。
查清真实 MySQL 版本，别信 Navicat 连接面板上写的
Navicat 在建立连接时缓存了一个版本号，这个值可能被代理、RDS 中间件或旧配置污染。必须手动执行：
-
SELECT VERSION();—— 看主版本，例如返回5.7.42-log就说明是 5.7 -
SELECT @@version_comment;—— 看有没有云厂商定制标记，如MySQL Community Server (Aliyun)，这类实例常阉割新特性
如果 VERSION() 返回的是 5.7.x，但 Navicat 连接属性里写的是 8.0.33，那它生成的所有 DDL 都默认按 8.0 写，保存表时就会把 utf8mb4_0900_ai_ci 或 ALGORITHM=INSTANT 这类东西塞进去，5.7 直接拒收。
Navicat 15 没有 Compatibility Mode，只能手改或绕过自动建表
Navicat 16+ 的导出/同步向导里有「Compatibility Mode」下拉菜单，可强制降级语法；但 Navicat 15 及更早版**根本没有这个选项**。这意味着：
- 新建表 → 点“保存” → 它会自动生成并执行一条
CREATE TABLE语句，且按它“以为的版本”拼写 - 你无法在界面上干预这个生成过程，只能事后补救
推荐做法是：先用 Navicat 新建表结构（不点保存），然后右键表名 →「复制为 SQL」→ 粘贴到文本编辑器里，全局搜索以下关键词并手动替换：
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
-
utf8mb4_0900_ai_ci→ 改成utf8mb4_unicode_ci -
ALGORITHM=INSTANT→ 整段删掉 -
DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP→ 删掉后半截，只留一个CURRENT_TIMESTAMP - 所有带单引号的列名或表名，如
'user_id'→ 改成反引号`user_id`（单引号是字符串定界符，不能包标识符）
别在查询编辑器里粘贴执行建表语句
把改好的 SQL 复制进 Navicat 查询编辑器里按 Ctrl+Enter 执行，看似方便，实则风险极高：
- Navicat 会隐式加
USE database_name，可能切错库 - 自动识别分号切分语句，但遇到存储过程或含分号的注释就容易断错位置
- 不处理 BOM 头、混合换行符（
\r\nvs\n），导致解析器提前卡住
正确做法是：菜单栏 →「文件」→「运行 SQL 文件」→ 选中你手改好的 SQL 文件 → 勾选「UTF-8 编码（无 BOM）」→ 执行。这种方式走服务端直读，跳过客户端预解析，成功率高得多。
最易被忽略的一点：Navicat 15 对 MySQL 5.7 的兼容性支持是“尽力而为”，不是“开箱即用”。它不会主动提醒你版本错配，也不会拦截高危语法——错误只在真正提交时才抛出，而那时你已经填完十几列、设好十几个索引，返工成本很高。所以每次连新库前，先跑两行 SELECT 确认版本，比反复调试建表报错省半小时。
