sqruff SQL 代码检查与格式化

要解决的问题

手写 SQL 的项目里，格式与风格很难保持一致：同一条查询在不同人手里可能缩进不同、关键字大小写不一，SELECT 之后字段的排列方式也各不相同。当 SQL 散落在多个文件、由多人长期维护时，这类不一致会让 code review 变得困难，也会让 diff 充满噪声。

另一个现实问题是速度。基于 Python 的 SQL Linter 在较大代码库上往往要等很久，团队要么放弃检查，要么降低检查频率，规则也就慢慢形同虚设。

工作原理

sqruff 用 Rust 重写了检查与格式化流程，目标是把「解析 → 检查 → 改写」放进一次足够快的执行里：

• 可配置的检查规则：规则并非写死，项目可以按自己的规范调整，而不是被迫接受工具的默认风格。
• 自动化格式化：规则明确后，由工具统一改写空白、缩进与换行，减少人工整理格式的工作量。
• 浏览器 Playground：想快速试一条规则、或看某种写法的格式化结果时，可以先在 playground 里验证，再决定是否落到项目配置。

典型流程是：对一段 SQL 运行 lint，得到规则命中与位置信息；确认结果后执行格式化，由工具产出风格统一的 SQL；规则调整时重新跑一遍，整个项目即可再次收敛。

适用边界与注意点

• 它解决的是风格与一致性问题，不是 SQL 语义正确性检查，也不替代执行计划或数据分析。
• 规则需要项目自行配置。团队若已有明确的 SQL 规范，接入前要先对齐规则，否则格式化结果可能与预期不符。
• 格式化会重写文件内容，建议先确认变更范围，避免一次性产生过大的 diff。
• 该技能是对上游 sqruff 的封装，具体行为取决于上游版本与项目配置。