Mini DBA SQL Server execution plan controls help you inspect query plan XML from live Activity, Cached SQL, Query Store, Profiler, and database detail workflows. Use this page when a SQL Server query is expensive, blocked behind a plan-related access pattern, or has changed behavior after a deployment, statistics update, parameter change, or index change.
Where To Open SQL Server Plans
SQL Server plans can be opened from several Mini DBA pages when SQL Server exposes a plan handle or Query Store plan and the monitoring account has enough permission:
- SQL Server Activity for currently running sessions and requests.
- SQL Server Cached SQL for expensive statements represented in plan cache.
- SQL Server Query Store for historical query and plan behavior.
- SQL Server Database Query Store for database-scoped Query Store review.
- SQL Server Database Detail for database query tabs and selected expensive queries.
- SQL Server Profiler for recent statement capture where plan XML is available.
Plan availability depends on SQL Server version, permissions, cache state, Query Store state, and whether the query still has a retrievable plan. A missing plan does not mean the query is harmless; it may have aged out of cache, run under a different database context, or require additional permission.
Main SQL Server Plan Viewer Controls
The SQL Server plan viewer starts with the Plan tab and shows the execution plan parsed into statements and operators. The header can include controls to copy the plan XML or open the XML in a separate browser tab. These are useful when you need to attach the plan to a support ticket, compare it with another tool, or preserve evidence before a plan disappears from cache.
The Statements grid lists each statement in the batch. It shows batch cost percent, operator count, shortened T-SQL text, and estimated rows. If the plan contains multiple statements, start with the highest batch percent or the statement that matches the query text from the incident.
The Operators grid shows the selected statement's operators ordered by estimated cost percent. It includes physical operator, logical operator, estimated rows, estimated I/O, and node ID. This is the fastest way to drill down based on expensive operators. Select the high-cost operator, then review the right-side detail panel before deciding what to tune.
Operator Detail
When you select an operator, Mini DBA shows details such as cost, I/O, CPU, estimated rows, average row size, execution mode, node ID, and whether the operator is parallel. It also shows object and predicate text where available, and the XML for the selected operator.
Use operator detail to answer practical tuning questions:
- Is the query scanning more rows than expected?
- Is a lookup operator repeated enough to justify a covering index?
- Is a sort, hash match, spool, or exchange operator dominating estimated cost?
- Are predicates being applied after a scan instead of driving a seek?
- Are row estimates inconsistent with what the query actually returns?
- Is the expensive operator linked to one table, index, predicate, or join?
Do not treat estimated cost percent as the only truth. SQL Server estimated plans can be misleading when cardinality estimates, statistics, parameter sniffing, or runtime waits distort the picture. Use Mini DBA runtime metrics from Activity, Cached SQL, Query Store, Waits, CPU, and I/O pages to confirm the operator matters in production.
Statement Properties, Parameters, Warnings, And Missing Indexes
When no operator is selected, the right-side panel focuses on the statement. The T-SQL tab shows the statement text. Properties can include degree of parallelism, non-parallel plan reason, compile time, compile CPU, compile memory, and optimizer statistics usage.
The Parameters tab shows compile-time parameters where available. This helps investigate parameter sensitivity and parameter sniffing. A plan compiled for a very selective parameter can behave badly for a broad parameter, and the opposite can also happen.
The Warnings tab highlights plan warnings. Review warnings before changing indexes because they can point to spills, conversion problems, missing statistics, or other plan-quality risks.
The Missing Indexes tab shows missing index requests embedded in the plan XML. Treat these as evidence, not instructions. SQL Server missing index suggestions can omit included columns, ignore write overhead, duplicate existing indexes, or optimize one query at the expense of the workload. Compare suggestions with SQL Server Indexes, Query Store impact, and write activity before creating an index.
Using Query Store Plan History
When a plan is opened from Query Store, first check the query's plan buckets and the selected time range. Query Store helps answer whether the query has multiple plans, whether one plan became worse, and whether a release or maintenance window lines up with the regression.
Use the plan viewer to inspect the selected plan, then compare it with runtime history. If one plan has much higher average duration, CPU, reads, or wait time, focus on the operator differences between the good and bad plans. Record query ID, plan ID, database, time range, and the operator evidence before proposing a force-plan, index, statistics, or query rewrite action.
Ask AI About A SQL Server Plan
The AI Assistant tab sends the plan XML and source context to the Mini DBA AI Assistant. In the execution plan viewer, Metrics and Sessions are disabled by default for the plan-specific AI prompt so the model focuses on the plan. You can still use the page-level AI Assistant from Activity, Queries, Query Store, or Waits when you want broader server context.
Useful prompts include:
Explain the highest-cost operators and rank the safest investigation steps.Does this plan point more toward missing indexes, stale statistics, parameter sensitivity, or query rewrite?What should I verify in Query Store before changing this query?For BYO AI and token guidance, see Mini DBA AI Assistant.
Related Pages
- Execution Plan Analysis
- SQL Server Activity
- SQL Server Cached SQL
- SQL Server Query Store
- SQL Server Database Detail
- SQL Server Performance Tuning