Mini DBA Azure SQL execution plan controls help you inspect query plans for Azure SQL Database workloads from Activity, Queries, Profiler, and Query Store. Azure SQL tuning uses many of the same plan concepts as SQL Server, but service tier, resource governance, elastic pools, and database-scoped permissions can change how the evidence should be interpreted.
Azure SQL execution plans can appear from:
Plan availability depends on the Azure SQL service, monitoring permissions, Query Store settings, plan cache behavior, and whether the selected query has plan data for the selected period. If a plan is not available, continue with query metrics, waits, locks, service tier data, and elastic pool evidence.
Azure SQL plan XML is displayed with the same rich Mini DBA execution plan viewer used for SQL Server plan XML. The viewer groups the plan by statements and operators, then lets you drill into details for the selected statement or operator.
The Statements section helps when a batch or captured query contains more than one statement. Use batch cost percent, operator count, SQL text, and estimated rows to choose the statement that matches the performance symptom.
The Operators section is the main drill-down area. It lists operators by estimated cost and shows physical operator, logical operator, estimated rows, estimated I/O, and node ID. Use it to identify scans, lookups, sorts, hash operations, joins, and other operators that may explain high CPU, high I/O, or long duration.
When you select an operator, Mini DBA shows cost, I/O, CPU, estimated rows, average row size, execution mode, node ID, parallelism, object and predicate details, and the XML for that operator. This lets you move from a general "query is expensive" conclusion to a more useful question: which table, predicate, join, or access method should be checked next?
For the selected statement, Mini DBA can show T-SQL text, compile properties, compile-time parameters, warnings, and missing index suggestions embedded in the plan XML. These areas are especially useful for Azure SQL because a query may degrade because of plan quality, service tier pressure, or both.
Review:
Do not create every missing index suggested by a plan. Azure SQL storage, write overhead, maintenance cost, and elastic pool pressure all matter. Compare the suggestion with Azure SQL Indexes, Query Store runtime history, and application write patterns.
Azure SQL Query Store is often the best place to investigate plan regressions because Query Store keeps historical runtime and plan data inside the database. Start with the incident time range, then select the query and inspect plan buckets. If the same query used multiple plans, compare duration, CPU, reads, writes, execution count, and wait time before opening the plan viewer.
When you load a plan from Query Store, keep the plan ID and time range with your notes. If the issue began after a release, schema change, statistics update, compatibility change, or service-tier change, plan history can help show whether the query changed shape or whether the environment around it became constrained.
Azure SQL plan analysis should not ignore platform capacity. A plan that was acceptable yesterday can appear slow today if the database is throttled, the elastic pool is saturated, or the workload burst exceeds the service objective. If an operator looks expensive, also check:
The execution plan viewer includes an AI Assistant tab that passes the selected plan XML as focused context. Use it when you want a quick explanation of plan shape, risky operators, missing index evidence, or likely next checks. Ask the assistant to separate plan-quality recommendations from service-tier or elastic-pool recommendations so you do not tune the query when the real issue is shared capacity, or scale the database when the plan is clearly inefficient.
Useful prompts include:
Which operator best explains the Azure SQL resource cost and what should I verify next?Could this be a plan regression, elastic pool pressure, or both?Summarize the plan evidence for a developer without recommending an unsafe index change.