Navicat 17 的 SQL 格式化功能默认关闭，需手动开启“工具 → 选项 → 编辑器 → SQL 格式化”中的「启用SQL格式化」；建议设为手动模式、关键字统一大小写、关闭「合并简单语句」并调整换行策略。
SQL格式化按钮点不动，先确认“启用”开关开了没
navicat 17 的 sql 格式化 功能默认是关闭的，不是装完就自动生效。很多人按 ctrl+shift+f 或右键选“格式化”没反应，第一反应是软件坏了——其实只是开关压根没打开。
路径是：工具 → 选项 → 编辑器 → SQL 格式化，必须勾选「启用SQL格式化」。这个设置是全局的，换连接、切数据库都不会重置。
容易忽略的点：
- 如果勾了「自动格式化」，每次敲分号或回车都会触发，干扰编码节奏；建议选「手动」模式
- 切换数据库类型（比如从 MySQL 切到 PostgreSQL）后，该页面的预设规则会变，但开关状态不会自动同步，得手动再确认一次
格式化后关键字全小写或乱改函数名，检查大小写规则和目标数据库类型
Navicat 会根据当前连接的数据库图标（右上角显示的 MySQL/PG/Oracle 图标）自动适配关键字大小写规则。但如果你连的是 MySQL，却在写兼容 PostgreSQL 的语法（比如用双引号括字段名），它可能误判 "id" 是标识符而非关键字，导致格式化后把 SELECT 改成小写，甚至把 COUNT() 强行改成 count()。
更麻烦的是：PostgreSQL 自定义函数名大小写敏感，my_func() 和 MY_FUNC() 是两个函数，格式化一改就执行报错。
解决办法：
- 在
SQL 格式化设置页，把「关键字大小写」设为「全部大写」或「全部小写」，别选「按数据库类型」 - 如果必须保留大小写差异，临时切换连接类型（比如右键连接 →「编辑连接」→ 把类型改成 PostgreSQL）再格式化
- 避免在函数名后直接跟括号写法如
TO_CHAR(，中间加空格可降低误判率
格式化把多行 SELECT 压成一行，重点调「换行策略」和「合并语句」
默认配置下，SELECT a, b, c FROM t WHERE x = 1 很可能被压成单行，可读性崩坏。这不是 bug，是规则里「简单语句合并」和「最大行宽」共同作用的结果。
关键参数在 SQL 格式化 → 换行与缩进 页：
- 取消勾选「合并简单语句」——否则
INSERT INTO t VALUES (1); SELECT * FROM t;会被合成一行，破坏语义分隔 - 把「每行最大字符数」调小（比如从 120 改成 80），强制换行
- 「逗号后换行」和「WHERE 后换行」这类细粒度开关要打开，否则条件堆一起很难维护
- 注释紧贴逗号或括号（如
name VARCHAR(32) -- 用户名）会导致换行异常，建议前面加空格，或改用/* */块注释
格式化后执行报错，优先排查注释位置和双引号字段名
格式化本身不改逻辑，但会动空格、换行、大小写——这些微小改动可能触发语法错误。最典型的是：
MySQL 里字段名用反引号 `user_id` 是安全的，但如果你手写成了双引号 "user_id"，而 Navicat 当前连接类型是 MySQL（不支持双引号标识符），格式化时又开了「统一引号类型」，它可能把所有双引号转成反引号，也可能直接删掉——结果就是语法报错。
另一个高频坑是注释位置：
-
CREATE TABLE t (id INT -- 主键)：注释紧跟括号后，格式化可能把它顶到行尾，导致括号不闭合 -
SELECT * FROM t WHERE id = 1-- 注释：末尾无空格，格式化可能吞掉--前的空格，变成1--注释，部分驱动会截断解析
这类问题不会在格式化界面报错，但一执行就失败。真遇到，先复制格式化后的 SQL 到纯文本编辑器里肉眼扫一遍空格和引号，比查日志更快。
