Press "Enter" to skip to content

Curated SQL Posts

Red Flags in Query Design

Thomas Williams has a list:

Nowadays I look after 3rd-party databases more than internally-developed ones, so I accept there’s a whole lot of ex-best practices, vendor preferences, and possibly shortcuts in queries I might come across – whether it’s a poorly-performing query, a blocker, or an error.

(Although, when I developed software more frequently, I was guilty of all the gripes below. My start in SQL, last century, was poring over a big yellow “For Dummies” book. I was the dummy.)

Click through for the list. I particularly hate tibbling, a rather derisive term for the malformed version of Hungarian notation. This would just lead me down a rant about how systems Hungarian notation was a mess, whereas apps Hungarian notation can be useful in certain circumstances. Tibbling provides no semantically valuable information, which is why I dislike it so much.

Leave a Comment

JSON Index Testing in SQL Server 2025

Reitse Eskens gives it a whirl:

In today’s cloud era, Azure SQL is usually first with new functionality, while on-premises SQL Server follows. One of the new things is the JSON data type and accompanying JSON index.

Because I had to learn how JSON works in SQL Server for my DP-800 exam, I decided to see how the JSON index works and when it works. I’ll go into the execution plans, some details, and check out the statistics when a query runs. Just so you know, this is much deeper than the certification requires, so no need to get this all in your head for the exam.

Click through for a rundown of how this feature works on-premises and what you should be on the lookout for.

Leave a Comment

Solving the Maximum Flow Problem in T-SQL

Sebastiao Pereira implements the Ford-Fulkerson algorithm:

Graphs can be used to formulate mathematical models for many different applications and one particular type of problem to be solved deals with networks that transport some kind of resource from one endpoint to another, like water or electricity. Is it possible to create using only SQL Server features?

What’s neat about this is that this sort of flow algorithm also works for, say, complex ETL processes. Also, in case you were as curious as I was, that map is Dresden.

Leave a Comment

T-SQL Code Smells

Rob Farley has a few:

I feel like I should preface this with a disclaimer. I added “potentially-” to the title, because there are many queries that might seem bad but can actually perform just fine. There are queries that on the surface can be great, but are nasty without a particular index, and there are queries that make me cringe a little when looking at them, but are actually okay. Brent Ozar is asking about signs of bad code for this month’s T-SQL Tuesday (the 200th – and I have a response for all 200 if you look back through my history of posts), and he wants us to write this for 2004 Brent, rather than 2026 Brent.

Click through for what Rob has come up with. I agree with all of Rob’s examples and do appreciate his usage of the APPLY operator as a way of solving one common problem.

Leave a Comment

The Never-Ending Query

Andy Yun doesn’t like it:

You know THE ONE I’m talking about… it has numerous sub-queries and CTEs… JOIN after JOIN after JOIN… predicates within predicates. Or maybe it’s just an obscene MERGE statement. 

These are particularly painful to deal with because it’s hard to test the pieces in isolation and ensure that an issue earlier in the process doesn’t bite you later.

Leave a Comment

Traits of Sketchy Queries

Louis Davidson has a list of red flags in code:

I still feel like garbage, so I decided just a simple list would do. I will also preface this by saying each item could include “without a coherent comment.”

Everything on this list fills me with dread unless I read someone say: “Such and such was needed because the optimizer wouldn’t….” and then I at least know why they believed needed it.

Click through for Louis’s list. Most of these aren’t bad things per se, but they do serve as signs of a potential deeper issue.

Leave a Comment

Red Flags in Database Code

Tom Zika has a list and starts with AI-generated code:

This one didn’t exist three years ago. Now it’s the first thing I look for.

To be clear, I’m not anti-AI. If the AI wrote clean code, I probably wouldn’t even notice. The red flag isn’t that AI generated it – it’s the patterns that give it away. I recently saw a real case where someone needed to update a set of values. Simple enough, right? Here’s what the AI-generated solution did:

Click through for a laugh, as well as several other red flags.

Leave a Comment

When All Joins are Left

Hugo Kornelis gives an example of a red flag:

This anniversary edition is hosted by Brent Ozar. And his chose topic is: query red flags. Things that make you groan when you open a query and see them in the code. I’m sure there will be a ton of posts, because there are so many. I myself could probably fill a book with things I consider a red flag (and someone else would then point out that my queries have things that they consider red flags, but that is another discussion).

But let’s focus on just one thing in this post.

Hugo selects the case when all query joins are LEFT OUTER joins. Especially when the logic of the query mandates INNER joins.

Meanwhile, if all of your query joins are RIGHT OUTER joins, you’re just chaotic evil.

Leave a Comment

The Siren Song of Code Reusability in SQL Server

Reitse Eskens hits on a long-standing pain point in SQL Server:

In an effort to make code reusable, someone decided to use Scalar User-Defined Functions. About ten of them. And each function was called in the SELECT list of each query sent to the database.

The worst part is, the instincts behind doing something like this are perfectly reasonable. In most programming languages, composing functions or refactoring code into isolated functions that you call is so cheap as to be (almost) free. But in T-SQL, that is rarely the case.

Leave a Comment

Starting Points for Query Tuning

Deborah Melkin shares some tips:

This one is really timely for me as I just started a new job. Performance tuning was part of the interview process so I’m really excited to dive back into doing more of that day-to-day. In fact, I just got added to the email reports with the top SQL results for the worst performers. Here’s some of what I’ll start looking at in that list and why:

Click through for Deborah’s red flag list. Of note, a red flag is not necessarily a bad thing. But it does merit further inspection and comment. For example, there may be specific instances in which join hints are necessary—you know you’re joining from a very small filtered subset to grab a tiny percentage of a bigger table (and you have an appropriate index on said bigger table), and so you slap on a LOOP join hint because the optimizer keeps trying to sort and merge join. But it’s worth explaining why and figuring out if there’s a better way, especially considering the consequences of slapping on that join hint.

Leave a Comment