在 Navicat 中，SQL 格式化功能默认处于关闭状态——若未手动开启，即便反复按快捷键也无法生效。许多用户排查许久，最终发现症结就在于此。
确认「启用 SQL 格式化」开关并重启
九成以上的“无响应”问题都源于此环节。Navicat 与其他编辑器不同，安装后不会自动激活格式化功能，需用户手动“启用”该权限，且修改配置后必须重启程序才能生效。
- Windows：工具 → 选项 → 编辑器 → SQL 格式化 → 勾选
启用 SQL 格式化 - macOS：Navicat → 偏好设置 → Editor → SQL Formatting → 勾选
Enable SQL formatting - 勾选完成后必须退出 Navicat 并重新启动，否则所有快捷键、右键菜单及工具栏按钮仍处于禁用状态
- 该设置为全局生效，切换连接或数据库不会重置此配置
确保你在正确的编辑器里按快捷键
Ctrl+Shift+F（Windows）或 Cmd+Shift+F（macOS）仅在「SQL 编辑器」中有效，并非所有文本框均可触发该功能。
- 焦点必须位于 SQL 编辑区域：例如双击视图打开的编辑页、新建查询标签页（Query / New Query），且光标在语句内部闪烁
- 在「Data」结果页、「Structure」表结构页、左侧对象树以及命令行（Command Line）模式下按下快捷键，均无任何响应
- Mac 用户需留意：
Cmd+Shift+F可能被系统或 Chrome 等应用抢占，推荐右键编辑区选择Format SQL更为可靠 - 未选中文本时，格式化作用于整个文档；选中部分则仅处理所选段落——请勿误判为“无反应”
调对三个关键参数，避免格式完更难读
Navicat 的格式化引擎不解析业务逻辑，仅按规则硬性排版。效果不佳，通常是参数设置与个人习惯不匹配所致，而非软件缺陷。
Indent width：设置为4（避免使用 8），嵌套 JOIN 或子查询时缩进过宽会导致代码超出屏幕显示范围Wrap after N characters：设置为80～100，防止长 WHERE 条件压缩成超长单行Uppercase keywords：建议关闭。小写关键字（select、where）在 Git diff 和团队协作中更易与变量名区分，且 Navicat 对大小写混合 SQL 的解析更为稳定- 额外提醒：
Put each clause on new line与Align multiple conditions需配合开启，否则AND/OR会出现缩进错位，易被误认为语法错误
格式化后执行报错？小心这些隐性改动
格式化并非纯文本替换，而是尝试解析语法树。一旦改动超出边界，可能悄然破坏语义结构。
- 自动删除行尾空格或制表符，可能导致
/*+ USE_INDEX(t1 idx_a) */等 hint 注释错位或截断 - 对反引号
`处理不稳定：MySQL 下含空格的表名如`order`，格式化后可能遗漏反引号，变为order从而引发语法错误 - UNION 子查询字段类型不一致时，格式化会暴露隐式转换问题（例如
INT与VARCHAR并列） - 若 SQL 包含 MyBatis 的
${}或RETURNING），格式化器可能直接卡死，弹出Error formatting SQL: Syntax error near ...
最容易被忽视的一点是：格式化 ≠ 语法校验。它不会检查括号是否匹配、表是否存在、字段拼写是否正确——这些仍需人工核实或执行前预检。
