不能。navicat的“美化sql”仅调整格式（如缩进、大小写），不校验语义，无法识别select *、缺失索引等风险；团队规范需结合导出xml统一格式、sqlcheck进行语义检查，并通过ci拦截，三者协同缺一不可。
Navicat 的“美化 SQL”能当团队规范检查工具用吗
不能。它只改格式，不查语义——SELECT *、缺失索引的 WHERE、嵌套过深的子查询，美化后反而更“整齐”，但风险照旧。美化按钮点击再多次，也不会报错、不会拦截、更不会告诉你这句 SQL 在生产环境可能拖垮查询性能。
真正起作用的是导出并共享 navicat_sql_format.xml
团队统一格式的物理载体就是这个 XML 文件，不是口头约定，也不是截图发群里。它包含缩进宽度（如 <indent>4</indent>）、关键字是否大写、每个关键字是否换行等硬性参数。
- 导出前务必取消勾选「保留原有空格」，否则手写缩进会干扰自动对齐逻辑
- 导入后必须重启 SQL 编辑器窗口——已打开的标签页仍沿用旧规则，新配置不会热加载
- Navicat 16 和 17 导出的 XML 结构有微小差异，团队成员必须统一主版本，否则互相导入会失败
- 建议将文件存为
.navicat/format/navicat_sql_format.xml并提交到 Git，和代码一起受版本控制
为什么光靠 XML 还不够：SQL 质量必须用 sqlcheck 补位
XML 管格式，sqlcheck 管语义。比如 SELECT * FROM users 在美化后完全合法，但 sqlcheck -r 2 -f query.sql 会直接标出“高危：未限定字段”，并支持按风险等级过滤输出。
- CI 流程中加一句
sqlcheck -r 2 -f ./migrations/*.sql || exit 1，就能卡住不合规 SQL 合入主干 - 不同数据库需显式指定方言：
--dialect postgresql或--dialect mysql，否则默认按 MySQL 解析，PG 特有语法（如ILIKE）可能被误判 -
sqlcheck不依赖数据库连接，纯静态分析，适合集成进 pre-commit 或 CI/CD
AI 助手不能替代格式化规则，但能暴露规则盲区
Navicat 17 的 AI 助手生成 SQL 时，严格绑定当前活动连接的元数据与方言。你在 PostgreSQL 连接下让它写“查最近7天订单数”，它会用 CURRENT_DATE - INTERVAL '7 days'；切到 MySQL 连接重提一次，就自动换成 DATE_SUB(NOW(), INTERVAL 7 DAY)。它不会跨库对比，也不会提醒你某函数在另一库中根本不存在。
- 别复制粘贴 AI 生成的 SQL 到别的库——必须切换连接后重新提交自然语言描述
- JSON 字段操作这类边界场景（
->>vsJSON_EXTRACT()）AI 容易出错，必须人工核对 - AI 生成后务必点「运行」测试，很多问题（如
LIMITvsFETCH FIRST）只在执行时报错
格式统一真正的难点不在“怎么导出 XML”，而在于让所有人理解：格式只是表象，语义合规才是底线；XML 是起点，sqlcheck 是守门员，AI 是翻译员——三者缺一不可，且各自职责不能越界。
