Optimizations are WISdom's automated, AI-assisted recommendations for making a specific SQL Statement cheaper, faster, or both. This page covers how optimizations are selected, how credits work, and how to read the results. For the Optimizations Ready card and Recommended Optimization filter, see Overview; for the Queue for Optimization button and the Query Analysis flyout, see Details.
How candidates are selected
WISdom runs two paths that lead to an optimization:
- Automated scan – on a schedule, WISdom sorts all queries in the account by CPU consumption in descending order and selects the top N, where N equals the account's count of monitored instances. Each selected query is run through a proprietary optimization algorithm and then evaluated by AI trained on WISdom data. Results populate the Optimizations Ready card on Overview.
- On-demand request – from the Query Analysis flyout for a specific query (reached via Details), selecting Queue for Optimization submits that query through the same algorithm and AI evaluation.
Both paths draw from the same optimization credit pool and produce the same output: a Query Order of Operations write-up, a set of Recommendations, and ready-to-run Scripts.
Optimization credits
Each client is issued five optimization credits per monitored instance per year.
A credit is consumed only when a query is successfully optimized. If a query cannot be optimized, no credit is consumed, whether the request came from the automated scan or from a query queued for Optimization.
A query that has already been optimized cannot be optimized again. Optimization can only be requested for a SQL Statement resolved to a single Server, Database, Object, and statement hash; it isn't available from a grouped or aggregated view.
Requesting an optimization
- From Overview, drill into a query down to a specific instance and database (see Overview and Details for how each works).
- In the Query Analysis flyout, select Queue for Optimization.
- The button is replaced with an Optimization in Progress status while WISdom evaluates the query.
- When evaluation finishes, the status changes to Optimization Ready and the Recommendations and Scripts tabs populate.
If WISdom can't produce an execution plan for the query, the Recommendations tab shows Optimization Failed instead, and no credit is consumed.
Reviewing the results
Query Order of Operations
A plain-language walkthrough of how the query's execution plan runs, in the order SQL Server processes it. It calls out the operations driving the most cost, such as full scans, residual filters applied after a scan, or spools with a high rebind count.
Recommendations
A numbered list of specific changes, each labeled with a type:
| Type | Typical fix |
|---|---|
| Index Creation | Add a new index to support a seek that's currently a scan. |
| Index Modification | Add a key or included column to an existing index to remove a residual filter. |
| Column Type Modification | Persist a computed column, or change a column's type, so it can be indexed or compared efficiently. Corresponds to the Inefficient Column Types Observation on the Query Impact Analysis table. |
| Query Rewrite | Replace a pattern such as a correlated subquery, non-sargable predicate, or inefficient join with an equivalent that the optimizer can plan better. |
Scripts
Each recommendation that requires a database change has a matching script card, labeled with the same type, and containing the ready-to-run T-SQL. Scripts may include a comment warning when a change (such as dropping and re-adding a computed column) should be tested outside production first.
Scripts are generated recommendations, not verified migrations. Review execution plans, locking behavior, and index impact on a non-production copy of the database before running any script against production.
Example
A query against dbo.vw_funddeals_itd_rpt was flagged as inefficient with Query Rewrite and Missing Indexes observations. Queuing it for optimization produced:
- A Query Order of Operations explaining that a clustered index scan of
Security.Approval(687 MB) was reading every row to apply a residual filter on a non-persisted computed column, and that a downstream Index Spool was replaying an expensive subtree for each of roughly 116,000 outer rows. - Two Recommendations: persist the computed column and add a filtered index on it to eliminate the residual scan, and add a covering index on
CashFlowsto support the join columns already being filtered on downstream. - Matching Scripts for both, including the
ALTER TABLEstatements to persist the column and theCREATE NONCLUSTERED INDEXstatements for each new index.