SQLFluff SQL 代码检查与格式化

解决什么问题

SQL 开发里最常见的拖沓不是语法报错，而是风格漂移。同一条查询，不同人写出的换行位置、关键字大小写、缩进层级、逗号前后空格往往不一致；有团队用 dbt 做 ELT，模板变量和过滤器混进 SQL 后，部分工具会直接解析失败；Git 里一跑 git diff，格式化噪音和逻辑改动搅在一起，review 很难看。SQLFluff 的价值在于把「什么算干净 SQL」变成可执行的配置：先 lint 报告问题，再按需 fix 自动改写，让风格检查像 CI 里的单元测试一样稳定。

核心能力与关键步骤

覆盖 30+ SQL 方言
支持 ANSI SQL 以及主流方言，方言选择决定解析树怎么构建；用 CLI 执行时可通过参数指定方言，避免按 ANSI 解析 PostgreSQL 或 Snowflake 语法。

• sqlfluff lint：只读检查，输出违规清单，适合接入 pre-commit 或 CI 流水线。
• sqlfluff fix：在可自动修复规则上直接改写文件，逻辑修复仍需人工确认。
• 配置文件可限定规则集、缩进宽度、大写策略等，团队把同一份 .sqlfluff 放进仓库即可对齐标准。

支持 Jinja / dbt 模板
遇到 {{ ref(...) }} 这类模板语法时，可启用 Jinja 解析，SQLFluff 能解析模板结构后再检查 SQL；dbt 项目通常配合 --dialect 与模板渲染参数使用。

典型的三步流程

1. 选定方言并跑一次 lint，先看阻断级问题。
2. 对可自动修复项执行 fix，再跑一次 lint 确认没有引入新冲突。
3. 在 CI 中固化同一套配置，防止格式化差异混进主干。

适用边界与注意点

SQLFluff 不负责 schema 校验和查询计划优化，它解决的是语法与风格层面的一致性。开启 Jinja 解析时，建议先确认渲染依赖，避免变量未注入导致解析失真；fix 的改写范围有限，对复杂表达式要人工复核；方言之间若共用一份配置，最好区分目录或文件，不要把所有规则都塞在默认规则集里。