> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pawsql.com/llms.txt
> Use this file to discover all available pages before exploring further.
> ## Agent Instructions
> PawSQL 是一个产品：Cloud 是公网部署形态，Engine / Optimizer / Auditor / Advisor / Patroller 是同一产品的组件与交付形态，不是彼此独立的产品。 / PawSQL is a single product: Cloud is the public deployment form, while Engine / Optimizer / Auditor / Advisor / Patroller are components and delivery forms of the same product, not separate products.
> 术语以站内术语表为准：SQL 审核对应英文 SQL Review，查询重写对应 Query Rewrite，索引推荐对应 Index Recommendation；英文内容统一用 Review，不用 Audit。 / Use the site glossary for terminology: 审核 is SQL Review, 重写 is Query Rewrite, 索引推荐 is Index Recommendation; English content uses Review, never Audit.
> 引用能力范围或版本支持时以对应页面为准；标注 unknown、或 status 非 published 的内容表示尚未经产品核实，不应作为事实引用。 / Cite capability scope and version support from the corresponding page; content marked unknown, or with a status other than published, is not yet product-verified and must not be cited as fact.
# 企业统一 SQL 治理平台
> 面向多团队、多数据库和复杂研发流程，PawSQL 帮助企业建立统一的 SQL 治理平台，覆盖开发、交付、生产和持续优化，形成端到端的 SQL 全生命周期治理体系。
## 用户
工程负责人、CIO / CTO、架构师、数据库平台主管与技术治理委员会——需要跨团队、跨数据库、跨研发流程统一 SQL 治理的组织。
## 问题
大型企业的 SQL 治理往往不是「缺工具」，而是「碎片化」：不同团队各自维护规范文档、依赖 DBA 人工审核、使用自研脚本；SQL 分散在 IDE、代码仓库、CI/CD、迁移脚本、生产慢日志等各个阶段；问题往往到生产环境才暴露。
治理能力已经存在，但缺乏统一体系。
## 目标
把分散的 SQL 工具与人工流程沉淀为统一、可执行、可度量的治理平台，形成跨团队、跨数据库、跨研发流程的 SQL 全生命周期治理。
## 流程
企业 SQL 治理可划分为三个核心层次，彼此形成闭环：
```mermaid theme={null}
flowchart TD
A[开发治理] --> B[交付治理] --> C[生产治理] --> A
```
三个层次分别对应一个使用场景（点击查看各自端到端流程）：
| 层次 | 回答的问题 | 对应场景 |
| ---- | ---------------- | -------------------------------------------------- |
| 开发治理 | 写 SQL 时是否合理？ | [开发者 SQL 智能优化助手](/use-cases/developer-sql-copilot) |
| 交付治理 | 是否允许进入生产？ | [CI/CD SQL 质量门禁](/use-cases/sql-quality-gate-cicd) |
| 生产治理 | 运行中的 SQL 是否持续健康？ | [生产慢 SQL 批量治理](/use-cases/slow-sql-optimization) |
三者共享同一套底层 SQL 分析能力，而非三套独立工具。
## 依赖能力
统一平台由以下能力支撑（详见各能力页）：
## 成功标准
| 指标 | 目标 |
| ----------- | -- |
| SQL 自动分析覆盖率 | 提升 |
| 上线前问题修复率 | 提升 |
| 严重 SQL 上线数量 | 降低 |
| DBA 人工审核量 | 降低 |
| 生产慢 SQL 数量 | 降低 |
| 治理规则统一率 | 提升 |
| 多数据库治理覆盖率 | 提升 |
***
## 一套规则，覆盖多个团队与数据库
统一治理不是「所有团队一套完全相同的规则」，而是「统一底线 + 业务差异化」：
```text theme={null}
集团基线规则 + 业务单元规则 + 项目专属规则
```
同时，多数据库治理也不等于「完全相同的检查」。正确的模型是：
```text theme={null}
统一治理框架 + 数据库专属智能
```
企业规范可以配置为自定义 SQL 规则，在开发、CI/CD、发布审核多个环节复用，避免「同一条规范由不同工具重复实现」。
## 从文档规范到策略即代码
几十页的《SQL 开发规范》本身不会阻止错误 SQL 上线。成熟的做法是把规范转为可执行策略：
```text theme={null}
规则：UPDATE 无 WHERE 条件
等级：严重
动作：阻断流水线
```
治理从「人记住规范」转变为「系统自动执行规范」。
## 让治理可度量
统一平台的价值还在于管理层获得统一指标：
| 指标 | 本月 | 趋势 |
| --------------- | ------: | -- |
| SQL 分析量 | 128,642 | ↑ |
| 严重问题 | 186 | ↓ |
| 上线前修复问题 | 4,382 | ↑ |
| 生产慢 SQL Pattern | 312 | ↓ |
并进一步建立 SQL Quality Score 与团队 Scorecard，把治理从「一次性审核」升级为「可度量的工程体系」。
## 典型实施路径
大型企业不建议一次性上线全部能力，可分阶段推进：
1. **统一 SQL质量检查**——先统一规则与数据库覆盖
2. **CI/CD 质量门禁**——接入 Git、CI/CD、Webhook，实现策略自动执行
3. **开发左移**——把 SQL 分析接入 IDE 与开发流程
4. **生产治理**——接入慢查询与监控，建立持续性能治理
5. **治理度量**——建立 Dashboard、Scorecard、Quality Score，把治理从工具能力升级为管理体系
## 从审核到治理，从优化到工程
企业最终获得的不是「SQL 审核工具」或「SQL 优化工具」，而是由标准、策略、分析、优化、工作流与指标共同构成的 SQL Engineering 能力。