Find the queries that hurt — and get told exactly why.

"The database is slow" is not a work item.

Turning a vague complaint into a prioritised list of concrete changes usually means hand-writing DMV queries, reading plan XML by eye, and knowing which anti-patterns to grep for. This tool does all three at once and hands you the shortlist.

What it needs.

This is a standalone Windows desktop application, not a PowerShell module — it doesn't need dbatools or PowerShell to run. It's a native rewrite of the earlier PowerShell sqmRefactorTool wizard, built by the same author as the rest of this toolchain.

Sixteen rules, run against every module.

Each rule scans the T-SQL token stream — a dependency-free tokenizer, not a full parser — for a specific, well-understood problem. Anti-patterns (AP) and formatting rules (FMT) run offline on a folder of .sql files as happily as they do against a live database.

Findings export to a self-contained dark-theme HTML report or to Markdown, both led by a prioritised "Action Items" list — the highest-severity, highest-impact findings across every rule, first.

What the optimizer is actually doing, in plain language.

Against a live database, the tool reads cached plans and index DMVs and turns them into findings — no plan XML to decode by hand.

These rely on the plan cache and DMVs, so they reflect what has actually run recently — read-only, and honest about their limits: a cached plan holds compile-time estimates, and where a value only exists in an actual plan the tool says so rather than guessing.

The operator tree, with the real problems in red.

Double-click any query-plan finding to open the execution plan as a graphical operator tree. Box colour is a cost heat map; edge thickness scales with estimated row count — the same "fat pipe" idea SSMS uses. But cost only tells you what's expensive, not what's broken, so decisive problems get their own fixed highlight: an operator with a critical plan warning (a tempdb spill, a cross join with no predicate) is drawn solid red no matter how cheap it looks, and lesser warnings get an amber border. A cheap-but-broken operator can't hide next to an expensive-but-fine one.

When a plan has been evicted from the cache, the visualizer falls back to Query Store automatically — so plans survive restarts and eviction — and the window title tells you which source it used. You can save any statement's plan as a .sqlplan file for full-detail viewing in SSMS or Azure Data Studio, and open a .sqlplan a colleague sends you completely offline.

Which object should you fix first?

A flat findings list doesn't tell you where to start. The Problem-Queries tab groups every finding by object and ranks them by a severity- and impact-weighted score — an object racking up a SELECT *, a cursor, a cardinality mismatch, and a missing index is empirically a worse query than one with a single formatting nit, and this surfaces that automatically. Select a row to see every finding for that object, plus any ready-to-use improvement suggestion (like QP009's generated CREATE INDEX). It's a different lens on the same scan, not a second engine.

Prove the cleanup actually landed.

Save the current findings as a JSON baseline, then compare a later scan against it: new, fixed, and unchanged since the baseline. For recurring engagements on the same database, that turns the report from a snapshot into a progress record. The comparison ignores the volatile numbers embedded in plan messages, so it doesn't report the same problem as both fixed and new every run. Available in the GUI and headless for CI.

Scriptable for build pipelines and CI/CD.

The same engine that drives the GUI is available from the command line — for gating a build on new anti-patterns, or generating a report as a pipeline artifact.

SqlRefactorAnalyzer.exe --scanfolder <folder> [--savebaseline <file.json>]   # Scan *.sql, optionally save a baseline
SqlRefactorAnalyzer.exe --scanfolder <folder> --comparebaseline <file.json>   # Diff against an earlier baseline
SqlRefactorAnalyzer.exe --report <folder> html|md <outfile>              # Scan + write a report
SqlRefactorAnalyzer.exe --dbscan <server> <database> [--plananalysis]     # Live scan incl. plan/index analysis

Why it's built this way.

Read-only by design

Every database interaction is a SELECT against a catalog view or DMV. The tool never issues DDL or DML, never modifies a scanned .sql file, and never stores a password — SQL-authenticated connections re-enter the password each session.

.NET Framework 4.8, on purpose

Target machines are DBA workstations and jump hosts that don't reliably have a modern .NET desktop runtime. .NET Framework 4.8 ships with Windows, so deployment is a folder copy — no installer, no runtime prerequisite. A GitHub Actions workflow packages the ready-to-run build as a ZIP on every release tag.

Token stream, not a full parser

Rules scan a flat token stream rather than a full T-SQL parse tree — a documented trade-off shared with the rest of this toolchain. It keeps the tool dependency-free and fast; the edge cases where a token scan can mis-bound a clause are documented per rule, not swept under the rug.

Scan a folder today, point it at a database next.

The offline folder scan needs nothing but the executable; the plan analysis and visualizer add value the moment you connect to a live instance.