> ## 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.
# Slow SQL Optimization at Scale
> From slow-query collection and SQL normalization to query rewriting, index recommendation, and execution-plan validation, PawSQL helps DBAs turn production slow SQL troubleshooting into an automated, scalable performance engineering process.
## Audience
DBAs and database operations teams responsible for production slow SQL governance.
## Problem
Production slow SQL governance isn't hard because of a lack of tools — it's hard to scale:
1. **Too many slow queries** — thousands a day, many of them the same pattern with different parameters
2. **Slow doesn't mean the SQL itself is wrong** — it may be index bloat, data growth, lock contention, or resource contention
3. **Knowing it's slow isn't knowing how to fix it** — the real cost is analyzing the cause, designing the rewrite, and judging the index
4. **Advice lacks validation** — "add an index" is far less useful than "which index, and is it actually faster after the change"
## Goal
Turn manual firefighting into automated, scalable batch governance, so DBAs focus on the SQL most worth optimizing instead of chasing slow queries one by one.
## Workflow
PawSQL connects production slow SQL governance into a sustainable loop:
```mermaid theme={null}
flowchart TD
A[Production Database] --> B[Slow Query Collection] --> C[SQL Normalization / Dedup]
C --> D[SQL Pattern Grouping] --> E[Performance Analysis]
E --> F["Query Rewrite
Index Recommendation
Execution Plan Analysis"]
F --> G[Performance Validation] --> H[DBA Review] --> I[Deployment] --> J[Continuous Monitoring]
```
## Dependencies
Built from the following capabilities (see each capability page for rewrite rules and index-design logic):
## Success Criteria
| Metric | Objective |
| --------------------------------------- | ----------------- |
| Daily slow query count | Decrease |
| SQL pattern count | Remain manageable |
| Automated analysis coverage | Increase |
| Queries with actionable recommendations | Increase |
| Average DBA handling time per SQL | Decrease |
| High-value optimization completion rate | Increase |
| Recurring slow SQL rate | Decrease |
***
## SQL Normalization: Collapse Many Executions into a Few Patterns
Most production slow SQL differs only in literal values:
```sql theme={null}
SELECT * FROM orders WHERE customer_id = 10001;
SELECT * FROM orders WHERE customer_id = 10002;
SELECT * FROM orders WHERE customer_id = 10003;
```
After normalization, they become one SQL pattern:
```sql theme={null}
SELECT * FROM orders WHERE customer_id = ?;
```
"100,000 executions" collapse into "1,000 SQL patterns", moving governance from individual queries to SQL patterns.
## Priority Model: Optimize What's Worth It, Not What's Slowest
Latency alone isn't the only signal — a query run 20,000 times a day at 800ms is more worth optimizing than one run 5 times a day at 30s. Consider:
```text theme={null}
Optimization Priority = Execution Time × Frequency × Resource Impact × Risk Level
```
## A Typical Batch Outcome
In one campaign, DBAs no longer analyze thousands of queries one by one:
```mermaid theme={null}
flowchart TD
A["Raw Slow Queries
2,386"] --> B["SQL Normalization
312 Patterns"]
B --> C["Automated Analysis
198 with Clear Opportunities"] --> D["High Priority
61"]
D --> E["DBA Review
45 Selected"] --> F["Validation Passed
39"]
F --> G[Production Deployment]
```
Only a few dozen high-value SQL patterns need focused attention.
## Complement Your Monitoring and APM
APM and database monitoring are good at "where is it slow"; PawSQL answers "why, how to fix it, and whether the fix actually helps":
```mermaid theme={null}
flowchart TD
A["Monitoring / APM"] --> B[Detect Performance Problem]
B --> C[PawSQL] --> D["Analyze · Rewrite · Index · Validate"]
D --> E[Validated Optimization]
```