Way back in December of 2009, Adam Machanic published a blog post (archive) in which he invited database bloggers to participate in a new monthly event he called T-SQL Tuesday. Each month, he (or a blogger he picked) proposed a topic, and on that date, we'd all publish our blog posts at the same time. It was a fun way to get a variety of opinions about a topic.
Normally when I tell people about SQL Server's optimistic concurrency isolation levels, Read Committed Snapshot Isolation (RCSI) and Snapshot Isolation (SI), I have to give them a little speech about how they need to test their queries because the results can change. Recently, though, I was working with a client who was getting the wrong query…
If you do a lot of query tuning, you've probably come across Richie Rump's StatisticsParser.com. Now, it's even easier to use.
Now, it's even easier to use. Download & install it, then run your query with SET STATISTICS IO, TIME ON, and after it finishes, right-click in the query window and click Parse Statistics:
I love me some documentation.
For years, I've pointed folks to the SQL Server 2008 documentation on Forced Parameterization, a really useful tool for reducing plan cache bloat, getting more accurate reusable query plans, and enabling SQL Server 2019 and 2022's Intelligent Query Plan features, many of which rely on the same query text coming in repeatedly over time in order to tune it. That documentation was pretty sparse, though.
At least once a month, I get this question from a client:
We have big data, and we want to save money. We want to move the older data down to some kind of archives that will cost us less.
When there are IF branches or conditional logic, "Edit Query Text" only shows you the branches that actually executed. It's easy to miss whole swaths of code that didn't happen to execute one particular time.
To demo it, let's create a simple stored procedure with an IF branch that sometimes executes, and sometimes doesn't:
The short answer: in the real world, only the first column works. When SQL Server needs data about the second column, it builds its own stats on that column instead (assuming they don't already exist), and uses those two statistics together - but they're not really correlated.
For the longer answer, let's take a large version of the Stack Overflow database, create a two-column index on the Users table, and then view the resulting statistics:
Ever just need a quick visualization of some numbers to get a rough idea of the trend, like this:
Option 1: ask Copilot to write the query for you.
Copilot in SSMS has two parts. Usually people focus on the pop-out Copilot chat window, and that's useful for sure, but honestly I think you're going to get way more mileage out of the code completions feature, right away, because it blends in with your existing workflows. Let's say that I'm working with the Stack…
The official Azure SQL Dev's Corner blog recently wrote about how to enable soft deletes in Azure SQL using row-level security, and it's a nice, clean, short tutorial. I like posts like that because the feature is pretty cool and accomplishes a real business goal. It's always tough deciding where to draw the line on how much to include in a blog post, so I forgive them for not including one vital caveat with this feature.
A long time ago in a galaxy far, far away, SQL Server Management Studio was included as part of the SQL Server installer.
Back then, upgrading SSMS was not only a technical problem, but a political one too. Organizations would say things like, "Sorry, we haven't certified that cool new SQL Server 1982 here yet, so you can't have access to the installer." Developers and DBAs were forced to run SSMS from whatever ancient legacy version of SQL Server that their company had certified.
Normally, when SQL Server updates statistics on an object, it invalidates the cached plans that rely on that statistic as well. That's why you'll see recompiles happen after stats updates: SQL Server knows the stats have changed, so it's a good time to build new execution plans based on the changes in the data.
However, updates to system-created stats don't necessarily cause plan recompiles.
Some folks are seeing an ad at the top of their SSMS v22, like this one reported in the feedback site:
Today, Microsoft's using this to test ads for an upcoming conference. Interesting that they give deeper discounts to Reddit readers as opposed to SSMS users, but I digress. Tomorrow, they might be pushing SQL Server 2025 upgrades, or Microsoft Fabric, or Copilot, or whatever.
Say you've got a table with an identity column, something that's supposed to start at 1 and go up to a bajillion:
[crayon-6a3dbdd3391ff751161342/]
Back in March 2025 when Microsoft first announced that REGEX support was coming to SQL Server 2025 and Azure SQL DB, I gave it a quick test, and the performance was horrific. It was bad in 3 different ways:
The CPU usage was terrible, burning 60 seconds of CPU time to check a few million rows
It refused to use an index
The cardinality estimation was terrible, hard-coded to 30% of the table
In last week's Query Exercise, I challenged you to play some code golf to generate big spills with tiny T-SQL.
Today, I'm going to walk you through my thought process - the initial attempts I tried and failed with, and the discoveries I made along the way, because I think it makes for fun storytelling.
Nah, not necessarily. SQL Server's query optimizer behavior keeps changing with every freakin' version. Let's illustrate it with a simple query against the Stack Overflow Users table:
[crayon-6a3dbdd339f19690884094/]
When I was testing SQL Server 2025's new ability to limit TempDB usage with Resource Governor, I wrote a few fun diabolical demos. One of them was to generate giant spills to TempDB, quickly.
When you're looking at an actual (not estimated) query plan, and you see a yellow exclamation point on a sort operator, that means:
In the Query Plan Pop Quiz, questions 2 and 3 asked you about what the sizes of arrows on query plans meant. The good news is that almost all of you got Question 2 right, but the bad news is that the vast majority of you got Question 3 completely incorrect, and the saddest part of that is that you've been using that inaccurate knowledge to guide your query tuning - and wasting your time.
In last week's Query Plans Pop Quiz, the first question was, someone hands you these two queries and you get their estimated plans to decide which query to tune. Perhaps you get the estimated plans from SSMS, or from sp_BlitzCache, or from your monitoring tool. The question was, which query should you focus on tuning?…
