> ## 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 批量治理
> 从慢查询采集、SQL 归一化到查询重写优化、智能索引推荐与执行计划验证，PawSQL 帮助 DBA 把生产慢 SQL 治理从人工逐条排查升级为自动化、规模化的性能工程流程。
## 用户
DBA / 数据库运维团队，负责生产环境的慢 SQL 治理。
## 问题
生产慢 SQL 治理的难点不在「没有工具」，而在「难以规模化」：
1. **慢 SQL 数量太多**——每天上千条，大量只是参数不同的重复模式
2. **慢不等于 SQL 本身有问题**——可能来自索引失效、数据增长、锁等待、资源竞争
3. **知道「慢」不等于知道「怎么改」**——真正耗时的是分析原因、设计改写、判断索引
4. **优化建议缺少验证**——「建议加索引」远不如「加什么索引、改后是否真的更快」
## 目标
把逐条人工救火，升级为自动化、可规模化的批量治理，让 DBA 聚焦「最值得优化的 SQL」，而不是逐条追着慢查询跑。
## 流程
PawSQL 把生产慢 SQL 治理串成一个可持续运行的闭环：
```mermaid theme={null}
flowchart TD
A[生产数据库] --> B[慢查询采集] --> C[SQL 归一化 / 去重]
C --> D[SQL Pattern 聚类] --> E[性能风险分析]
E --> F["查询重写优化
智能索引推荐
执行计划分析"]
F --> G[性能验证] --> H[DBA 复核] --> I[优化落地] --> J[持续监控]
```
## 依赖能力
由以下能力组合而成，具体改写规则与索引设计逻辑见各能力页：
## 成功标准
| 指标 | 目标 |
| ----------------- | ---- |
| 每日慢 SQL 数量 | 持续下降 |
| SQL Pattern 数量 | 可控 |
| 自动分析覆盖率 | 提升 |
| 自动产生优化建议比例 | 提升 |
| DBA 单条 SQL 平均处理时间 | 降低 |
| 高价值 SQL 优化完成率 | 提升 |
| 慢 SQL 重复发生率 | 降低 |
***
## SQL 归一化：把海量执行记录收敛成少量模式
生产环境大量慢 SQL 只是参数不同：
```sql theme={null}
SELECT * FROM orders WHERE customer_id = 10001;
SELECT * FROM orders WHERE customer_id = 10002;
SELECT * FROM orders WHERE customer_id = 10003;
```
归一化后统一为同一个 SQL Pattern：
```sql theme={null}
SELECT * FROM orders WHERE customer_id = ?;
```
于是「10 万条执行记录」收敛成「1,000 个 SQL Pattern」，治理对象从单次查询提升为 SQL 模式。
## 优先级模型：找「最值得优化的」，不是「最慢的」
单次耗时不是唯一标准——一条每天执行 2 万次、耗时 800ms 的 SQL，比一条每天 5 次、耗时 30s 的 SQL 更值得优先治理。综合考虑：
```text theme={null}
优化优先级 = 执行耗时 × 执行频率 × 资源影响 × 风险等级
```
## 一个典型治理结果
一次批量治理任务中，DBA 不再需要逐条分析几千条 SQL：
```mermaid theme={null}
flowchart TD
A["原始慢查询
2,386 条"] --> B["SQL 归一化
312 个 Pattern"]
B --> C["自动分析
198 个存在明确优化机会"] --> D["高优先级
61 个"]
D --> E["DBA 复核
45 个进入优化"] --> F["验证通过
39 个"]
F --> G[生产实施]
```
最终只需重点关注几十条真正高价值的 SQL。
## 与监控系统互补
APM / 数据库监控擅长回答「哪里慢」；PawSQL 更进一步回答「为什么慢、怎么改、改后是否真的更好」：
```mermaid theme={null}
flowchart TD
A["监控 / APM"] --> B[发现性能问题]
B --> C[PawSQL] --> D["分析 · 重写 · 索引 · 验证"]
D --> E[可验证的优化方案]
```