SQL Server Execution Plan Analyzer
Paste a query execution plan and get an instant read on where the cost is — expensive operators, missing indexes, spills and plan warnings — plus AI-backed index and rewrite recommendations.
What the SQL Server Execution Plan Analyzer does
The free Avesys Execution Plan Analyzer reads a SQL Server execution plan — the XML showplan that SQL Server Management Studio (SSMS) produces — and turns it into a plain‑English diagnosis of why a query is slow. It pinpoints where the cost actually goes, which operators dominate, which indexes are missing, and which plan warnings (tempdb spills, implicit conversions, residual predicates) are quietly hurting performance. Paste the plan or upload a .sqlplan file and you get a ranked, copy‑ready set of fixes in seconds — no signup, and the plan is parsed in memory, never stored.
What is a SQL Server execution plan?
An execution plan is the step‑by‑step strategy the SQL Server query optimizer chooses to run a query: which indexes it uses, the join algorithms it picks (nested loops, hash, merge), the order of operations, and the estimated cost of each step. Reading the plan is how you find the real reason a query is slow — a clustered index scan over millions of rows, a missing index, a hash spill to tempdb, or a cardinality estimate that sent the optimizer down the wrong path.
How to read an execution plan
- Operators (RelOps). Each node is one operation — Index Seek, Clustered Index Scan, Nested Loops, Hash Match, Sort. Large scans and repeated nested loops are the usual culprits.
- Operator cost %. SQL Server assigns an estimated cost to every operator. The analyzer ranks them by their own cost so you fix the true bottleneck first, not the biggest‑looking box.
- Estimated vs actual rows. A large gap means stale statistics or a bad estimate — the most common root cause of a query suddenly choosing a worse plan.
- Warnings. Spills to tempdb, implicit conversions, missing indexes and no‑join‑predicate warnings are each a concrete, fixable tuning lead.
How to get an execution plan in SSMS
- Estimated plan: press
Ctrl + L(Display Estimated Execution Plan) — the query isn't run. - Actual plan: turn on
Ctrl + M(Include Actual Execution Plan), then run the query. - Export it: right‑click the plan → Save Execution Plan As… for a
.sqlplanfile, or Show Execution Plan XML… to copy the XML. Paste either one above. - From T‑SQL:
SET STATISTICS XML ON(actual) orSET SHOWPLAN_XML ON(estimated); or pull a cached plan fromsys.dm_exec_query_plan.
What the analyzer checks for
- Expensive operators ranked by their own cost, not subtree totals
- Missing indexes — with a ready‑to‑run
CREATE INDEX(key +INCLUDEcolumns) and estimated impact - Table and clustered index scans that should be seeks
- Sort and hash spills to tempdb
- Implicit conversions that silently disable index seeks
- Cardinality mis‑estimates (estimated vs actual rows)
- AI‑ranked fixes and a safe query rewrite when one applies
Frequently asked questions
Is the SQL Server Execution Plan Analyzer free?
Yes — it's completely free and needs no signup. You can analyze up to 10 execution plans per day, and your plan is parsed in memory and never stored.
How do I get an execution plan in SSMS?
For an estimated plan, press Ctrl + L. For the actual plan, enable “Include Actual Execution Plan” (Ctrl + M) and run the query. Then right‑click the plan and choose “Save Execution Plan As…” to export a .sqlplan file, or “Show Execution Plan XML…” to copy the XML — paste either one into the analyzer.
What's the difference between an estimated and an actual execution plan?
An estimated plan comes from the optimizer without running the query and shows estimated row counts. An actual plan is captured after the query runs and includes real row counts and runtime statistics, which makes cardinality mis‑estimates and tempdb spills far easier to diagnose. Both are supported.
How does it find missing indexes?
When SQL Server believes an index would speed up the query, it embeds a missing‑index suggestion in the plan. The analyzer extracts that suggestion and generates a ready‑to‑run CREATE INDEX statement with the correct key and INCLUDE columns, along with its estimated impact.
What is a spill to tempdb and why does it matter?
When a Sort or Hash Match operator is granted less memory than it needs, it spills the overflow to tempdb on disk — replacing fast in‑memory work with slow physical I/O. The analyzer flags spills and points to the underlying memory‑grant or row‑estimate problem behind them.
Can I paste a .sqlplan file, or only XML?
Both. Upload a .sqlplan file or paste the raw showplan XML directly — including .sqlplan files saved as UTF‑16.
Is my SQL or plan data stored?
No. Your execution plan is parsed in memory to produce the analysis and is never written to disk or logged, and there's no signup required.
Does it work with Azure SQL and recent SQL Server versions?
Yes. Any standard SQL Server showplan XML works — SQL Server 2016 through 2022 and Azure SQL Database. The showplan schema is the same across versions.