Navicat不支持输入时自动大写SQL关键字，仅在美化（Ctrl+Shift+B）或自动补全时按“大写关键字”设置生效；该选项是格式化策略而非实时监听器，不影响手动输入内容。
Navicat 不支持输入时自动将关键字转为大写，所谓“自动转换”只存在于格式化（Ctrl+Shift+B）和自动补全两个环节，手动敲的 select 永远不会变成 SELECT。
为什么勾选“大写关键字”后手输内容还是小写
这个设置不是实时监听器，而是格式化策略开关。它只在以下两个时刻起作用：
- 你按下
Ctrl+Shift+B（Windows）或Cmd+Shift+B（macOS）执行美化时 - 你使用自动补全（比如输入
sel后按Tab），补全项会按该设置输出SELECT或select
它不解析当前光标前的 token，也不拦截键盘事件。所以你敲完 select * from users，它就保持原样——这不是 bug，是设计如此。
如何真正让已写 SQL 的关键字变大写
必须主动触发格式化，且确保前提条件满足：
- 先确认已启用格式化：Windows 路径为
工具 → 选项 → 编辑器 → SQL 格式化 → 勾选“启用 SQL 格式化”；macOS 是Navicat → 设置 → 编辑器 → SQL 格式化 → Enable SQL formatting，改完必须重启 Navicat - 打开查询编辑器，焦点落在 SQL 区域内（不能在结果网格或对象树）
- 勾选
格式 → 美化 SQL 选项 → 大写关键字，再点击格式 → 美化 SQL或按快捷键 - 如果只美化某一段，先选中那段再操作；否则默认处理全文
注意：Ctrl+F7 是旧版快捷键，新版统一为 Ctrl+Shift+B；若无反应，大概率是没重启或焦点不在编辑区。
哪些 SQL 容易被格式化“误伤”
Navicat 的格式化基于简单正则 + 预设规则，不走 AST 解析，对复杂结构容忍度低：
- 含 MyBatis 或 JPA 的动态 SQL（如
${id}、<if test="xxx">）会被识别为非法语法，直接跳过美化 - MySQL hint（如
/*+ USE_INDEX(t1 idx_a) */）可能被删空格或换行，导致 hint 失效 - 带反引号的标识符（如
`order`）有时漏掉反引号，变成order报错 - 嵌套子查询中
CASE WHEN的缩进可能错位，建议分段选中后单独美化
别指望一次全选美化就能搞定所有 SQL；真正要靠得住的，是养成写完就按 Ctrl+Shift+B 的习惯，并快速扫一眼是否破坏了语义。
最常被忽略的一点：格式化效果依赖三个参数协同——Uppercase keywords 控制大小写，Indent width 影响嵌套可读性，Wrap after N characters 决定长条件是否折行。单改一个，往往适得其反。
