Skip to main content
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

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: 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

1

Validate in a test environment

For rewrites, compare result consistency and check plans; for indexes, create the candidate and compare plans, time, and scan volume.
2

Run performance validation

Use the same environment, data, parameters, and session conditions to compare plans, cost, time, and resources.
3

Submit for review

Attach the original SQL, rationale, test evidence, capacity estimate, window, and rollback plan.
4

Deploy and observe

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

Read the results

Index recommendation capability