Common Table Expressions are awesome because they let SQL Server reorder processing in whatever way it deems to be the most efficient for your current data distribution, on your current version of SQL Server. Default to CTEs.
When SQL Server gets that process wrong, switch to temp tables.
Over the years, tables - like your waistline - tend to get bigger. We keep tacking on more and more columns, one at a time, in order to handle app needs. It's easier to add "just one more column" than it is to break things off into a whole separate table. When you're only handling…
For this month's T-SQL Tuesday, I invited y'all to tell me how you know a query's gonna be bad when you open it. Riccardo Perico and Shane O'Neill says WHILE loops and/or CURSORs are pretty good indicators. I agree, because especially when you're opening code in the year 2026, and someone still hasn't figured this out…
I open it up and the first thing I see is a comment with a changelog showing a long list of dates and author initials.
Oh I know, you think documentation is a good thing, but:
Microsoft SQL Server Management Studio 22.7 added the ability to format your T-SQL queries by right-clicking and clicking Format SQL, or by hitting control-K, control-Q on your keyboard:
You're probably not going to like the default formatting out of the box because you're the kind of person who has strong, passionate feelings and likes to argue about them on the Internet. Good news! The configurations are really flexible. Go into Tools, Options, SQL Formatter:
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-6a7b47086191f513163205/]
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
