Navicat SQL格式化需手动启用并重启生效，仅在SQL编辑器中响应快捷键，且依赖正确参数配置与语法规范。
navicat 的 sql 格式化功能默认是关闭的，不启用就永远没反应——哪怕你 ctrl+shift+f 按烂了也没用。
确认「启用 SQL 格式化」开关并重启
这是 90% 无效操作的根源。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 的格式化引擎不理解业务逻辑，它只按规则硬排。效果丑，大概率是参数和你的习惯不匹配，而不是 bug。
-
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 的
${}或<if>标签、未闭合引号、方言特有语法（如 PG 的RETURNING），格式化器直接卡死，弹出Error formatting SQL: Syntax error near ...
真正容易被忽略的是：格式化 ≠ 语法校验。它不会告诉你括号是否匹配、表是否存在、字段拼写是否正确——这些还得靠你肉眼或执行前预检查。
