Articles about SQL Server, from the trenches
Execution plans, indexes, performance tuning and Azure SQL — written from thirty years of hands-on DBA practice. New articles appear regularly.
Statistics Parser
Paste your STATISTICS IO/TIME output and get clear signals instantly — physical reads, worktables, skewed CPU/elapsed time. Free, 100% in your browser, with an optional full report by email.
Try the tool → -- parameter sniffing · PSP · newParameter Sensitive Plans (PSP) versus Parameter Sniffing
SQL Server 2022's Parameter Sensitive Plan optimization replaces the single cached plan with a dispatcher plus up to three query variants, bucketed by parameter cardinality. Tested against Posts.ParentId in the StackOverflow database — a column where a handful of values have thousands of matches and most have almost none — the rare and common cases each get their own optimized plan, visible as predicate_range and QueryVariantID markers in the execution plan.
Read on dbaronald.nl → -- string functions · execution plansExecution Plans of all String Functions
Thirty-three T-SQL string functions — from ASCII to UPPER — each tested against the StackOverflow2010 database, with a correlated scalar subquery that nudges the optimizer's cost estimate past the parallelism threshold so parallel plans show up. Every function comes with its own execution plan.
Read on dbaronald.nl → -- table variables · temp tablesTable Variables versus #Temp Tables
Table variables have no statistics? A common assumption — but on recent SQL Server versions, indexed table variables can carry real statistics too, visible right in the execution plan. Trust the plan, not the rule of thumb.
Read on dbaronald.nl → -- partitioning · index maintenanceYou Want to Partition Your Huge Table.. Ok Fine.. Let's Go.
Partitioning an existing huge table without a size-of-data operation: an empty partition function, two metadata-only SWITCH operations around a clustered index rebuild, then incremental SPLIT RANGE calls that seek instead of scan — Michael J. Swart's technique applied end to end.
Read on dbaronald.nl → -- join order · execution plansWhy Join Order Can Make or Break Your Query Performance
Seven variations of the same query on StackOverflow2013, differing only in join order and physical operator — one forces a 2.46M-row hash build, another burns 87% of its runtime on nested-loop iterations, all because the wrong side became the build/outer input.
Read on dbaronald.nl → -- query plan · aiAI and Where Does Query Time Go? Using Claude's Query Plan Analysis Skill
A scalar function hides where a query's time actually goes — Claude's execution-plan-analysis skill flags it, inlining with STRING_AGG and a composite index take it from slow to fast, with sp_BlitzCache and Performance Studio confirming the win.
Read on dbaronald.nl → -- query store · aiAutomate Executionplan Analysis by Skill and Query Store
Pull queries from Query Store, generate actual execution plans and have Erik Darling's execution plan skill for Claude Code analyze them automatically — with concrete performance recommendations as the result. (In Dutch)
Read on dbaronald.nl → -- ai · query tuningIs AI making an end to my job as a SQL Server query tuner?
A hands-on test: Claude reads an execution plan, spots an Index Spool built 613 times, and recommends the index that takes a query from 73 seconds to 435 ms. What's left for the human tuner?
Read on dbaronald.nl → -- query processing · seriesRereading Craig Freedman: the query processor blog that still holds up after 20 years
A reading guide to my ten-part series on Craig Freedman's classic query processing blog (2006–2010) — every concept re-tested on modern SQL Server, with real execution plans.
Read article → -- index maintenance · updatedIndexOptimize and additions to Ola Hallengren's dbo.CommandLog
Why an IndexOptimize job suddenly runs longer — and how a few extra columns pull page count, fragmentation, size and duration straight out of the ExtendedInfo XML in dbo.CommandLog.
Read on dbaronald.nl → -- performance tuningReading execution plans: what to check first?
Five checks that find the culprit in most plans within minutes: thick arrows, unexpected scans, key lookups, cardinality deviations and warnings.
Read article → -- indexesIndex tuning: clustered, nonclustered and included columns
How to choose the clustering key, why column order is everything, when INCLUDE pays off, and how to find and remove unused indexes.
Read article → -- performance tuningParameter sniffing: when one plan doesn't fit all
Why a stored procedure suddenly turns slow, how to recognise it in Query Store, and which of five fixes fits when.
Read article →