Press "Enter" to skip to content

Category: T-SQL Tuesday

Red Flags in Database Code

Published 2026-07-08 by Kevin Feasel

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.

Comments closed

Starting Points for Query Tuning

Published 2026-07-08 by Kevin Feasel

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.

Comments closed

The Siren Song of Code Reusability in SQL Server

Published 2026-07-08 by Kevin Feasel

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.

Comments closed

Proper Disdain for ANSI-89 Join Format

Published 2026-07-08 by Kevin Feasel

Andy Brownsword has it together:

It’s a legacy pattern, and thankfully it’s rare to see these in the wild nowadays.

The legacy OUTER JOIN syntax (*= and =*) which used to accompany these was deprecated, and finally removed in *checks watch* SQL Server 2012, so that’s one less reason to see the aging syntax.

Every time I see this format, I despise it. Andy explains exactly why. We’ve had better options for more than 30 years, yet people still choose to write code this way.

Comments closed

Pain Points for a Query

Published 2026-07-07 by Kevin Feasel

Vlad Drumea comes up with a list:

This is my list of “main suspects” that make me instantly think a query is bad as soon as I see at least one of them.

Note, this is just based on the query text alone, seeing the execution plan is an instant confirmation.

Now, without further ado and in no specific order:

Click through for the list. There are some good items on it.

Comments closed

The Pain of Functions Wrapping Columns in a WHERE Clause

Published 2026-07-07 by Kevin Feasel

Rebecca Lewis answers a question:

This post is part of T-SQL Tuesday #200, hosted this month by Brent Ozar. The prompt: “When I’m looking at a query, I bet it’s bad if I see ____.”

Easy. I didn’t even have to think about it. When I open a stored procedure and see a function wrapped around a column in the WHERE clause, I groan. Out loud. Because more often than not, it means the predicate is non-SARGable, and non-SARGable means your indexes just became very expensive shelf decorations.

That is a pretty good answer, yes. Almost nothing good comes from wrapping columns with functions in the WHERE clause or as part of a join criterion.

Comments closed

T-SQL Tuesday 199 Round-Up

Published 2026-06-22 by Kevin Feasel

Koen Verbeeck wraps up another T-SQL Tuesday:

A good week ago I hosted the monthly T-SQL Tuesday blog party. I invited the community the blog about the idea of what would happen if we would need to go back on-premises, after a good decade of cloud computing. What would you need to do? How do you plan for this? What are the skills you might need to (re-)learn? You can find my take on this here, where I’m telling my junior colleagues that troubleshooting issues on-prem is more challenging, because it’s possible you need to go way down, all the way to Kerberos, SAN and DNS issues.

Click through for the contributions.

Comments closed

On-Prem Is Still On-Prem

Published 2026-06-11 by Kevin Feasel

Andy Brownsword reminds us that it’s still the same animal:

Cloud solutions have sliders which magically reduce downtime, performance issues, and account credit. When you build it, infrastructure and platforms are your challenge, and you get one shot to right-size it. Capacity, resilience, capabilities. They’re your challenges to solve. There is no cake slider.

It’s the capabilities I want to consider here. The capabilities we have available to us day-to-day. Potentially two opposing sides:

To summarize things, everything is awful, just as it always has been. Granted, that may not be how Andy would summarize things, but that’s why I get those big Curated SQL bucks.

Comments closed

Re-Migration and Data Engineering

Published 2026-06-11 by Kevin Feasel

Andy Leonard shares some thoughts:

Right-sizing didn’t always work out the way some clients were led to believe it would.

In nearly every instance, the right-sizing argument was presented (sold) as the solution to over-provisioning, or purchasing hardware to serve peak loads. The classic example was a US income tax service that needed more and faster compute available to meet increasing demand starting in late January and peaking in mid-April each calendar year. After mid-April, hardware that was beefy enough to handle that peak load sat mostly idle for the next 9 months.

I don’t think I’ve ever worked for a company where this scenario really made sense. Even in the e-commerce company where a sizable fraction of our total annual revenues happened over a 5-day period, the load was still significant enough the rest of the year that we made good use of our on-premises SQL Server hardware.

Comments closed