我把PostgreSQL代码规范塞进CI/CD流水线后，DBA终于不骂我了

团队从MySQL切到PostgreSQL后，SQL脚本提交量暴增。开发写SQL随性，关键字大小写、索引命名（idx_user_id、user_id_idx、index1）混乱，Review时常被忽略。DBA警告：上月因索引命名不规范，ORM未识别已有索引导致重复创建，差点打挂生产库。我决心将SQL规范检查自动化。

选型与工具链

正则脚本难处理CTE、子查询等复杂语法。最终组合工具链：sqlfluff做风格检查，squawk做性能风险扫描，Python胶水脚本串联。

核心配置

项目migrations/目录存放SQL。.sqlfluff关键配置：

[sqlfluff]
dialect = postgres
max_line_length = 120
indent_width = 4

[sqlfluff:rules:capitalisation.keywords]
capitalisation_policy = upper

[sqlfluff:rules:naming.convention]
extended_capitalisation_policy = lower

注意：CREATE INDEX CONCURRENTLY易被误报，需加白名单。.squawk.toml排除不适用的规则，如事务内禁用的require-concurrent-index-creation。

GitLab CI集成

sql-lint:
  stage: lint
  image: python:3.11-slim
  before_script:
    - pip install sqlfluff squawk-cli
  script:
    - sqlfluff lint migrations/ --format github-annotation
    - squawk migrations/*.sql
  only:
    - merge_requests
    - main
  allow_failure: false

--format github-annotation将问题直接标注在MR的Diff视图，直观高效。首跑触发47条告警，团队抵触。为降低负担，引入自动修复。

通义千问自动修复

sqlfluff fix可处理风格问题，但复杂场景（如命名、注释）需LLM辅助。核心脚本：

import openai, os

client = openai.OpenAI(
    api_key=os.getenv("DASHSCOPE_API_KEY"),
    base_url="https://dashscope.aliyuncs.com/compatible-mode/v1"
)

def fix_sql_with_llm(sql_content: str) -> str:
    prompt = f"""你是PostgreSQL规范专家。修复以下问题：
1. 索引命名：idx_表名_列名
2. 表须加COMMENT
3. 优先varchar而非text
4. 关键字大写
直接输出修复后SQL：
{sql_content}"""
    response = client.chat.completions.create(
        model="qwen-plus",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.1
    )
    return response.choices[0].message.content

LLM理解到位，但需在prompt中约束（如避免强行将text改varchar）。自动修复作为CI可选Job，由/fix-sql评论触发，不打断流程。

效果与反思

上线一月，DBA态度缓和，主动Review出两条潜在风险SQL。落地关键点：

1. 渐进推进：新文件严查，存量逐步整改，减少阻力。
2. 自动修复：工具链覆盖90%场景，降低负担。
3. 结果可视化：MR内直接标注，比通知有效。
4. 规则可讨论：维护规范文档，注明原因和例外，避免教条。

规范本质是协作问题，工具用于达成共识、养成习惯。有流水线兜底，更踏实。下一步计划用Rust写Language Server，实现IDE内实时检查。