Azure SQL Performance Tuning

Start Here

Manual Home Installation Getting Started Licensing Servers Connect Database Servers Troubleshoot Connectivity Host OS Login Enable WMI Multi-Engine Settings

Console

Console Overview Enterprise View AI Assistant Execution Plans Alerts Custom Alerts Reports Settings Service Log Connectivity Log Web Log About

PostgreSQL

Overview Connection and Permissions Activity Databases Queries Waits Memory I/O Indexes Deadlocks Server Log Settings Permissions Health Checks Alerts Performance Tuning

MySQL/MariaDB

Overview Connection and Permissions Activity Databases Queries Memory I/O InnoDB Permissions Deadlocks Health Checks Alerts Performance Tuning

Oracle

Overview Connection and Permissions Activity Databases Queries Waits Memory Health Checks Alerts Performance Tuning

Settings And Integrations

Security SQL Options Email Server Alert Recipients Recipient Groups Server Groups Cloud Providers Web Proxy Slack Microsoft Teams PagerDuty Jira Performance Logging AI Provider MCP Server

Azure SQL Performance Tuning provides a guided performance review for Azure SQL logical servers and databases. It helps connect workload, Query Store, waits, indexes, service tier, and elastic pool evidence.

When To Use It

Query Store shows expensive queries.
Elastic pool usage is high.
Waits point to CPU, I/O, memory, or lock pressure.
Users report slow Azure SQL performance.
You need practical recommendations before changing service tier or indexes.

Workflow

Open Performance Tune for the Azure SQL server or database.
Review recommendations and evidence.
Validate findings with Queries, Query Store, Azure SQL Execution Plans, Waits, and Elastic Pools.
Open Performance Tuning With AI when you want Mini DBA AI Assistant to interpret the evidence or compare tuning options.
Apply changes through a controlled change process.
Review the same metrics after the change.

Azure SQL Tuning Strategy

Azure SQL performance tuning should consider both query shape and cloud resource limits. A query can be slow because it scans too much data, uses an unstable plan, waits on locks, or runs in a database that is competing for elastic pool resources. Before resizing, check whether query tuning, indexes, statistics, or concurrency changes can reduce the workload.

Use Performance Tune for a guided review, then validate with Query Store for history, Waits for bottleneck category, Locks and Deadlocks for concurrency, and Elastic Pools for shared resource pressure.