> ## 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.
# Evaluate and Apply Suggestions
> Evaluate the semantics, compatibility, benefit, and cost of rewrite and index suggestions, then apply them safely after testing and review.
Optimization suggestions are candidates, not deployment instructions. Whether a rewrite or an index recommendation, evaluate semantics, compatibility, benefit, and cost under one framework before applying.
## Goal
Evaluate the semantics, compatibility, benefit, and cost of rewrite and index suggestions, then apply them safely after testing and review.
## Prerequisites
You have completed optimization results with rewrite or index suggestions to evaluate.
## Decision framework
| Dimension | Question |
| -------------------- | -------------------------------------------------------------- |
| Semantic correctness | Does the candidate preserve the required result and behavior? |
| Compatibility | Does the target engine and version support it? |
| Performance | Do plans, cost, or measured metrics improve? |
| Operational cost | What changes in writes, storage, locking, and maintenance? |
| Release risk | Are testing, review, rollout, observation, and rollback ready? |
Generated SQL and index DDL are candidates, not production deployment instructions. Validate every change through your organization's engineering and release controls.
## Evaluating rewrites
When comparing the original and rewritten SQL, focus on:
* returned columns, data types, and column order;
* `NULL` semantics;
* duplicate-row and deduplication behavior;
* filter and join conditions;
* aggregation, ordering, pagination, and window functions;
* data-modification scope;
* target database compatibility.
Apply stricter consistency checks for `NULL`, outer joins, duplicate rows, non-deterministic functions, implicit casts, and DML. Do not adopt a rewrite just because it is shorter or has a lower estimated cost.
## Evaluating index recommendations
A recommended index is candidate DDL. When reading its definition, confirm the target table and schema, index type, key columns and order, included columns, filter conditions, uniqueness, and online-creation options.
Check its relationship to existing indexes:
| Relationship | What to check | Possible handling |
| ----------------------------- | ----------------------------------------------------- | ------------------------------------------- |
| Identical | Same key columns, order, and attributes | Usually do not duplicate |
| Existing index covers it | Recommended columns are a prefix of an existing index | Verify the existing index already suffices |
| It covers an existing index | The new index may replace a shorter one | Consider merging after evaluating other SQL |
| Same columns, different order | Different selectivity, ordering, and join needs | Verify separately, not by column set alone |
| Partial overlap | Each serves different workloads | Assess against the global SQL load |
Weigh benefit (fewer full scans, fewer rows read, better joins, less sorting, covering queries) against cost (slower writes, storage, creation time, lock impact, maintenance, distributed overhead).
## Applying suggestions
For rewrites, compare result consistency and check plans; for indexes, create the candidate and compare plans, time, and scan volume.
Use the same environment, data, parameters, and session conditions to compare plans, cost, time, and resources.
Attach the original SQL, rationale, test evidence, capacity estimate, window, and rollback plan.
Apply in the approved window and observe locks, load, space, write latency, and plan changes.
## When not to adopt
* SQL or objects did not fully parse;
* workspace does not match the target database;
* the rule rationale or conditions cannot be explained;
* result-consistency testing failed;
* the recommended index duplicates an existing one, or the table has high write pressure with benefit not justifying maintenance cost;
* the database did not actually use the index in the test environment;
* only estimated benefit exists without adequate validation.
## Recording decisions
For each suggestion, record adopted, adjusted, rejected, or pending, plus the owner, rationale, test environment and parameters, plan or performance data, planned rollout time, and rollback path.
## Expected Result
Suggestions that pass evaluation are applied in a test environment and then in production, with each decision recorded.
## Verification
Compare results and plans in a test environment, confirm the database actually uses a recommended index, and record each decision as adopted, adjusted, rejected, or pending.
## Next steps