The Azure SQL Queries page shows expensive or notable queries for an Azure SQL database. Use it to find statements driving CPU, reads, writes, duration, or repeated execution.
What To Review
- High CPU statements.
- High I/O statements.
- Long-duration statements.
- Recent expensive queries.
- Query text and plan detail where available.
Workflow
- Open Queries for the Azure SQL database.
- Sort by the resource that matches the symptom.
- Open query detail.
- Load the plan where available and drill into expensive operators.
- Compare with Query Store for history.
- Use Indexes and Performance Tuning for follow-up.
How To Prioritize Azure SQL Queries
Azure SQL tuning should balance query cost with service tier and pool limits. A query can look expensive because it is badly written, because it lacks a supporting index, because it runs too often, or because the database or elastic pool is undersized for the workload. Review duration, CPU, reads, writes, execution count, waits, and Query Store history together.
If the database is in an elastic pool, compare query spikes with Azure SQL Elastic Pools. A noisy neighbor database can make a query look worse even when its plan has not changed.
When plan XML is available, use Azure SQL Execution Plans to review statements, operators, warnings, parameters, and missing index evidence. This helps separate inefficient SQL from service-tier or elastic-pool pressure.
Azure SQL Query FAQ
Should I use Query Store or the Queries page?
Use both. Queries shows current or recently collected expensive statements. Query Store provides history, regressions, and plan context.
Does Azure SQL Query tuning differ from SQL Server?
The query tuning concepts are similar, but Azure SQL service tier, resource governance, and elastic pool behavior can be part of the cause.
Why do I need VIEW DEFINITION?
VIEW DEFINITION helps Mini DBA show schema, object, and plan-related context needed for useful query investigation.
Next Steps After Finding A Query
After selecting an expensive Azure SQL query, capture the query text or identifier, time window, database, runtime, reads, writes, CPU, and related wait evidence. Then compare the statement with Query Store for plan history and Indexes for schema support. This gives developers and DBAs enough context to test a targeted fix.